V4 Design: Record Processing - Revision history

MartyKraimer at 19:52, 2 November 2005

2005-11-02T19:52:08Z

← Older revision		Revision as of 19:52, 2 November 2005
Line 1:		Line 1:
	EPICS V4: Record Processing November 01 2005		EPICS V4: Record Processing November 02 2005

	----		----
Line 69:		Line 69:
	</center>		</center>

	V4 will provide ~~something analogous to V3~~ dbProcess.		V4 will provide a replacement for dbProcess.
	The name may be different but for now it will still be called dbProcess.		The name may be different but for now it will still be called dbProcess.

Line 80:		Line 80:

	V4 also allows support for <b>struct</b> fields.		V4 also allows support for <b>struct</b> fields.
	~~In particular~~ base provides support for		For example base provides support for
	field(common,struct(RecordCommon))		field(common,struct(RecordCommon))
	~~This field appears as the first field in~~ the record types provided with base		In the record types provided with base, this is the first field.
	~~and can also appear as~~ the first field ~~of other types~~.		The fields in <tt>RecordCommon</tt> are the V4 replacement for
	The fields in <b>RecordCommon</b> are the V4 replacement for
	the V3 dbCommon fields.		the V3 dbCommon fields.

Line 109:		Line 108:
	* block		* block
	** is requested via a separate field		** is requested via a separate field
	** if true than support waits for all outstanding I/O to complete before ~~calling link or struct support~~		** if true than support waits for all outstanding I/O to complete before further processing
	** if false than asynchronous support can proceed in parallel		** if false than asynchronous support can proceed in parallel
	* lock		* lock
Line 160:		Line 159:
	as a string with syntax that matches the information associated with the link.		as a string with syntax that matches the information associated with the link.
	For example a process link will have a string something like		For example a process link will have a string something like
	support(processLink) ~~PvProcessLink~~(pvname = 'pvname'; wait = true)		support(processLink) ProcessLink(pvname = 'pvname'; wait = true)
	where		where
	; <tt>processLink</tt>		; <tt>processLink</tt>
	: selects the support for a process link		: selects the support for a process link
	; <tt>~~PvProcessLink~~</tt>		; <tt>ProcessLink</tt>
	: Names the struct that the support uses for configuration information		: Names the struct that the support uses for configuration information

Line 186:		Line 185:
	** implements interfaces called by record and/or other support		** implements interfaces called by record and/or other support
	* struct support		* struct support
	** is responsible for ~~all~~ fields in the struct		** is responsible for the fields in the struct
	** implements interfaces called by record and/or other support		** implements interfaces called by record and/or other support

Line 205:		Line 204:
	*** processQuit - Record support just returns processQuit to dbProcess		*** processQuit - Record support just returns processQuit to dbProcess
	*** processActive - Record returns processActive. It will be called again with state processContinue. It calls RecordCommon support with state processActive. This continues until Record Common returns processDone or processQuit		*** processActive - Record returns processActive. It will be called again with state processContinue. It calls RecordCommon support with state processActive. This continues until Record Common returns processDone or processQuit
	* When RecordCommon returns processDone it starts processing record specific fields		* When RecordCommon returns processDone record support starts processing record specific fields
	** Associated link or struct support may be called		** Associated link or struct support may be called
	*** Record support implements any <tt>block</tt> fields.		*** Record support implements any <tt>block</tt> fields.
Line 234:		Line 233:

	* at the beginning of record processing		* at the beginning of record processing
	** ~~disable~~ - if true NO processing will be done, i.e. processQuit is returned		** disabled - if true NO processing will be done, i.e. processQuit is returned
	** scanDisable		** scanDisable
	*** has associated support		*** has associated support
Line 304:		Line 303:

	Each link and struct field has a well defined client.		Each link and struct field has a well defined client.
	* ~~dbProcess~~ is the client for fields in dbCommon		* The support for RecordCommon is the client for fields in dbCommon
	* record support is the client for the other top level fields in a record		* record support is the client for the other top level fields in a record
	* the struct support is the client for any link or struct fields in the struct		* the struct support is the client for any link or struct fields in the struct
Line 331:		Line 330:
	* Output Link:		* Output Link:
	** Put value		** Put value
	** Optionally request processing. ~~<b>If record can not be processed should the value be changed?</b>~~		** Optionally request processing.
	** Optionally wait until completion		** Optionally wait until completion
	* Process Link: Perform the following actions		* Process Link: Perform the following actions
Line 361:		Line 360:
	** process passive database links and forward links were implemented via recursive calls to DbProcess		** process passive database links and forward links were implemented via recursive calls to DbProcess
	** Lock sets prevented deadly embrace problems for circular links.		** Lock sets prevented deadly embrace problems for circular links.
	* No puts could be done to an record in a lock set while record processing is active.		* No puts could be done to a record in a lock set while record processing is active.
	** For synchronous records this guarantees that no fields are modified except by record processing itself.		** For synchronous records this guarantees that no fields are modified except by record processing itself.
	** For asynchronous records this guarantee is not valid.		** For asynchronous records this guarantee is not valid.
Line 445:		Line 444:
	* alarmSeverity will ONLY be posted if it has changed since the last time it was posted		* alarmSeverity will ONLY be posted if it has changed since the last time it was posted

	The semantics, which are implemented by ~~recordCommon~~, are:		The semantics, which are implemented by the support for RecordCommon, are:

	* When recordCommon is called with processStart		* When recordCommon is called with processStart
Line 519:		Line 518:
	record.field(link)		record.field(link)
	The data will be appear in the form:		The data will be appear in the form:
	choice(choiceName) SupportStruct(pvname= ,;...)		choice(choiceName) SupportStruct(pvname= ...)
	where <tt>choiceName</tt> is the name of the link support, <tt>SupportStruct</tt> is the name of the support struct asociated with the support, and the arguments are the values for the support structure.		where <tt>choiceName</tt> is the name of the link support, <tt>SupportStruct</tt> is the name of the support struct asociated with the support, and the arguments are the values for the support structure.

Line 543:		Line 542:
	== DbfLink ==		== DbfLink ==

	~~Both of these have the following:~~		A string with the same syntax as defined for a link field in "V4 DB Record Instance Syntax"

	* <tt>choiceName</tt> A ~~string that selects the link support.~~
	* <tt>dataStructName</tt> Each support has an associated struct for configuration.

	~~How should these be made available? Perhaps:~~

	~~The field appears as a~~ string with ~~the following syntax:~~

	~~<tt>choiceName(structAssignmentList)</tt>~~

	~~where structAssignmentList has~~ the same syntax as defined in "V4 DB Record Instance Syntax"

	== timeStamp ==		== timeStamp ==
Line 564:		Line 552:

	== struct ==		== struct ==

	~~The database definition syntax allows a struct to be composed of fields~~
	~~of any DbfType.~~
	~~Database access, however, will only allow access to structs with fields~~
	~~of the following types:~~
	* primitive - DbfBool,...,DbfFloat64
	* DbfString
	* DbfArray of primitive type or string
	* DbfStruct - As long as its fields are valid types

	The individual fields can be accessed directly so this discussion		The individual fields can be accessed directly so this discussion
	only involves access to the entire structure.		only involves access to the entire structure.

	~~Access will only~~ be ~~available to clients that have knowledge of~~		The entire structure can be accessed as a string with the same syntax
	~~fields within~~ the ~~structure. For channel access clients this means that~~		as defined for a struct field in "V4 DB Record Instance Syntax"
	~~they provide~~ a ~~propertyCatalog that has some subset of the fields~~ in ~~the structure.~~

MartyKraimer at 20:09, 1 November 2005

2005-11-01T20:09:11Z

Show changes

MartyKraimer at 14:25, 21 October 2005

2005-10-21T14:25:42Z

Show changes

MartyKraimer at 20:07, 27 September 2005

2005-09-27T20:07:47Z

Show changes

MartyKraimer at 16:03, 23 September 2005

2005-09-23T16:03:11Z

Show changes

MartyKraimer at 15:24, 16 September 2005

2005-09-16T15:24:20Z

Show changes

MartyKraimer at 15:47, 15 September 2005

2005-09-15T15:47:32Z

Show changes

MartyKraimer at 15:34, 1 September 2005

2005-09-01T15:34:44Z

← Older revision		Revision as of 15:34, 1 September 2005
Line 1:		Line 1:
	= EPICS V4: Record Processing =		= EPICS V4: Record Processing =
	~~August 30~~ 2005		September 1 2005

	----		----
Line 70:		Line 70:
	V4 record processing has the following features not available in V3:		V4 record processing has the following features not available in V3:

	* ~~All links~~ to other records:		* Links to other records:
	** Can request that the linked record be processed		** Can request that the linked record be processed
	** Can wait until the linked record completes processing		** Can wait until the linked record completes processing
Line 81:		Line 81:
	=== Link Semantics ===		=== Link Semantics ===

	The link semanics are similar for 1) database ~~links, 2)~~ channel access links,		The link semanics are similar for database and channel access links (
	and 2) ~~a channel access process variable link~~.		input, output, and process).
	All provide the ability to request processing and to wait until processing completes.		All provide the ability to request processing and to wait until processing completes.

Line 111:		Line 111:

	Monitors are posted by dbProcess when		Monitors are posted by dbProcess when
	* record support ~~is called with and~~ returns processActive.		* record support returns processActive.
	* ~~during~~ the ~~last part~~ of record processing.		* at the end of record processing.


	=== Database Field Types ===		=== Database Field Types ===

	~~The early releases of~~ V4 support Channel Access and Database Access to the		V4 support Channel Access and Database Access to the
	following types of fields:		following types of fields:

	* primitive types		* primitive types
	* string		* string
	* one dimensional array of primitive or string		* one dimensional array of primitive or string or struct
	* struct with fields of following types:		* struct with fields of following types:
	** primitive		** primitive
	** string		** string
	** array of primitive or string		** array of primitive or string or struct

	~~Later releases will provide access to more complicated~~ fields.		NOTE: The struct fields must by a BasicType as defined in dbdInterfaces.

	<center>		<center>
Line 143:		Line 143:
	Links are processed as follows:		Links are processed as follows:

	* Input Link: Perform the following actions		* Input Link: Two flavors are available
	** Optionally request that record be processed.		** Monitor Link
	** Optionally wait for record to complete processing.		*** Implemented via a monitor request on linked field
	** Get value.		*** Optionally process record containing the link when monitor value is returned.
			** Input Link: Perform the following actions
			*** Optionally request that record be processed.
			*** Optionally wait for record to complete processing.
			*** Get value.
	* Output Link: Two varieties are available		* Output Link: Two varieties are available
	**Output Only: Perform the following actions		**Output Only: Perform the following actions
Line 345:		Line 349:
	* If other record completion callback requests are present, call them.		* If other record completion callback requests are present, call them.
	* post monitors		* post monitors
	* ???
	* The record is set idle.		* The record is set idle.

Line 427:		Line 430:
	</center>		</center>

	The document "V4 Design: dbdIterfaces" provides a design that		The document "V4 Design: dbdIterfaces" provides a design that allows
	~~allows dbAccess~~ to ~~detect all changes to fields of an IOC record.~~		database access to handle all posting on monitors without requiring

	~~dbAccess handles~~ all posting on monitors without requiring
	any help from the code that modifies database fields.		any help from the code that modifies database fields.
			It can do this because fields can be modified only via an
	~~Monitors are handled as follows:~~		interface implemented by database access.


	~~Monitors~~ are ~~implemented~~ in two ways:		Fields are modified in one of two ways:
	* Changes made while record is being processed. ~~These are~~ handled by dbProcess.		* Changes made while record is being processed. For these posting is handled by dbProcess.
	* Changes by other code. ~~These are~~ handled by dbLock/dbUnlock.		* Changes by other code. For these posting is handled by dbLock/dbUnlock.

	Each field of a record instance has two associated "modified" bits.		Each field of a record instance has two associated "modified" bits.
Line 444:		Line 445:
	by dbLock/dbUnlock.		by dbLock/dbUnlock.


	~~The first way is changes made while a record is being processed.~~
	dbProcess posts monitors when:		dbProcess posts monitors when:
	* When record support returns processActive.		* When record support returns processActive.
Line 464:		Line 463:
	* post - Create storage, copy the current value of the field into the storage, and pass the storage to the monitor subsystem.		* post - Create storage, copy the current value of the field into the storage, and pass the storage to the monitor subsystem.


	~~The problem is how to implement posting.~~
	Separate discussions is required for the following: 1) primitive fields,		Separate discussions is required for the following: 1) primitive fields,
	2) string fields, 3) structured fields, and 4) array fields.		2) string fields, 3) structured fields, and 4) array fields.
Line 523:		Line 520:
	</center>		</center>

	~~NOTE: This topic still needs lots of discussion.~~

	=== Overview ===		=== Overview ===
Line 532:		Line 528:
	For the initial V4 implementation only the following types of data		For the initial V4 implementation only the following types of data
	will be accessable.		will be accessable.
	~~(Later releases of V4 will support more complicated types.)~~

	* primitive types		* primitive types
	* string		* string
	* enum		* enum
	* one dimensional array of primitive or string		* one dimensional array of primitive or string or struct
	* struct with fields of following types:		* struct with fields of following types:
	** primitive		** primitive
	** string		** string
	** enum		** enum
	** one dimensional array of primitive or string		** one dimensional array of primitive or string or struct

			The dbdInterfaces document defines database field types.
			It also defines a subset called basic types, which consists
			of primitive types, string, array, and structure.
			For external access only base types can be accessed.
			This means that structures and arrays that do not consist of basic types
			are not accessable outside the record. For example a DbfLink is
			not accessable via channel access as a DbfLink.

			Non basic fields will only be available via some combination of basic types.

	~~Other fields will only be available as one of the above types.~~
	For example a DbfLink field will appear as a string.		For example a DbfLink field will appear as a string.
			If a Database Definition is
	~~Since the field view provides access to subfields of a field and to~~
	~~elements of an array, information from every DbfType is available.~~

	~~As an example if~~ a Database Definition is

	struct(calcInpLink) {		struct(calcInpLink) {
Line 670:		Line 669:
	The typical example is a client that asks for timeStamp, severity, status,		The typical example is a client that asks for timeStamp, severity, status,
	and data.		and data.
			These are handled automatically as described in "Posting Modifications"
	These is handled automatically as described in "Posting Modifications"

MartyKraimer at 19:46, 30 August 2005

2005-08-30T19:46:03Z

← Older revision		Revision as of 19:46, 30 August 2005
Line 1:		Line 1:
	= EPICS V4: Record Processing =		= EPICS V4: Record Processing =
	August 25 2005		August 30 2005

	----		----
Line 8:		Line 8:
	</center>		</center>

	<~~bold~~>UNRESOLVED ISSUES</~~bold~~>		<b>UNRESOLVED ISSUES</b>
	* Channel/Database access types:		* Channel/Database access types:
	** What are the supported types for struct fields?		** What are the supported types for struct fields?
Line 170:		Line 170:
	* When a record has multiple input links the links can be processed in parallel or sequentially		* When a record has multiple input links the links can be processed in parallel or sequentially
	* When a record has multiple output links the links can be processed in parallel or sequentially		* When a record has multiple output links the links can be processed in parallel or sequentially




	----		----
Line 188:		Line 185:
	processState is passed to process (iocRecord or record support) and is also		processState is passed to process (iocRecord or record support) and is also
	returned by process. processState defines the states:		returned by process. processState defines the states:
			; processCancel
			: If record support is called with this state, it must terminate outstanding processing and prepare for being called with processIdle.
	; processIdle		; processIdle
	: record is not being processed		: record is not being processed
Line 220:		Line 219:

	When dbProcess is called the action it takes depends on processState.		When dbProcess is called the action it takes depends on processState.
			* processCancel - Stop any existing processing and prepare for state processIdle
	* processIdle		* processIdle
	** prepare the record for processing		** prepare the record for processing
Line 254:		Line 254:
	some by record support, and some by link support.		some by record support, and some by link support.

			=== processState processCancel ===
			When process (Record Support or iocRecord) is called with this state
			it just prepares for being called again with state processIdle.

			An example of when process is called with this state is when a Channel Access
			request is made to modify a link or device field in a record instance that is not idle. If this happens, record support and/or iocRecord will be called
			to cancel any outstanding internal state.
			Process does not have to call link or device support because Database Access
			will call the cancel method of any link or device support attached to
			the record.
	=== processState processIdle ===		=== processState processIdle ===
	When dbProcess is called with processIdle it:		When dbProcess is called with processIdle it:

MartyKraimer at 18:21, 25 August 2005

2005-08-25T18:21:43Z

← Older revision		Revision as of 18:21, 25 August 2005
Line 1:		Line 1:
	= EPICS V4: Record Processing =		= EPICS V4: Record Processing =
	August 24 2005		August 25 2005

	----		----
Line 7:		Line 7:
	== Overview ==		== Overview ==
	</center>		</center>

			<bold>UNRESOLVED ISSUES</bold>
			* Channel/Database access types:
			** What are the supported types for struct fields?
			** What are the supported types for arrays.?
			* Monitored data
			** What are semantics for monitors that involve large amounts of memory?

	This document described the semantics for V4 record processing.		This document described the semantics for V4 record processing.
Line 19:		Line 26:
	This version is based on feedback from the EPICS core developer's		This version is based on feedback from the EPICS core developer's
	meeting at ANL/APS on July 11th through July 14th.		meeting at ANL/APS on July 11th through July 14th.
	In addition discussions with Andrew Johnson and Eric Norum have ~~provided~~		In addition discussions with Andrew Johnson and Eric Norum have
	led to many of the ideas described below.		led to many of the ideas described below.
	This wiki is a companion to the wiki "V4 Design: dbdInterfaces".		This wiki is a companion to the wiki "V4 Design: dbdInterfaces".
Line 67:		Line 74:
	** Can wait until the linked record completes processing		** Can wait until the linked record completes processing
	* While record support is active a record can still be processed and post monitors.		* While record support is active a record can still be processed and post monitors.
	* Database links are ~~not~~ processed via recursive calls to dbProcess		* Database links are processed via queue requests rather than recursive calls to dbProcess.
	* ~~Lock~~ sets ~~do not exist. Instead~~ each record instance has a lock.		* Instead of lock sets, each record instance has a lock.
	* Monitors are implemented by database access without help from record support		* Monitors are implemented by database access without help from record support
	* Channel Access and Database Access can access arrays and structures		* Channel Access and Database Access can access arrays and structures
Line 80:		Line 87:
	=== Processing Database Links ===		=== Processing Database Links ===

	In V3 ~~record~~ linked via database links are processed via recursive calls to		In V3 records linked via database links are processed via recursive calls to
	dbProcess. In V4 this will no longer be done. For V4 the following is done		dbProcess. In V4 this will no longer be done. For V4 the following is done
	when a link requests processing:		when a link requests processing:
Line 102:		Line 109:
	In V3 monitors are posted when code (record support, device support, database access, etc) calls db_post_event. In V4 database access will itself handle		In V3 monitors are posted when code (record support, device support, database access, etc) calls db_post_event. In V4 database access will itself handle
	the posting of monitors.		the posting of monitors.

	~~All changes to database fields are done via an interface implemented by database~~
	~~access. This makes it possible for database access to handle monitors.~~

	Monitors are posted by dbProcess when		Monitors are posted by dbProcess when
Line 113:		Line 117:
	=== Database Field Types ===		=== Database Field Types ===

	The early releases of V4 ~~will~~ support Channel Access and Database Access to the		The early releases of V4 support Channel Access and Database Access to the
	following types of fields:		following types of fields:

Line 310:		Line 314:
	This state means that one or more output links handled by iocRecord have not		This state means that one or more output links handled by iocRecord have not
	completed.		completed.

			iocRecord returns either
			* processOutputActive - record support returns and when called again calls iocRecord with processOutputActive.
			* processDone - dbProcess does final processing as described next.


Line 368:		Line 376:
	Note that if all linked records are passive and the same priority then		Note that if all linked records are passive and the same priority then
	all processing can occur without any context switches.		all processing can occur without any context switches.
	~~The~~ following ~~occurs~~:		For example the following can happen:
	* A request is made to a thread to call dbProcess.		* A request is made to a thread to call dbProcess.
	** The request is put on a queue associated with the thread.		** The request is put on a queue associated with the thread.
	* Sometime later the request is dequeued and dbProcess is called.		* Sometime later the request is dequeued and dbProcess is called.
	** For each link process request the request is put on the queue for the same thread		** For each link, with a request to process request, the request is put on the queue for the same thread
	** After all requests are queued dbProcess returns		** After all requests are queued dbProcess returns
	* The thread takes each request off the queue and calls dbProcess for the associated linked record		* The thread takes each request off the queue and calls dbProcess for the associated linked record
Line 438:		Line 446:
	* When dbUnlock is called it		* When dbUnlock is called it
	** posts all fields that have changed		** posts all fields that have changed
	** sets the associated modify ~~bit~~ false		** sets the associated modify bits false

	The following is the initial attempt to describe how monitors are implemented.		The following is the initial attempt to describe how monitors are implemented.
Line 487:		Line 495:
	** A private variable prevSeverity is set to alarmSeverity		** A private variable prevSeverity is set to alarmSeverity
	* When iocRecord completes its part of record processing		* When iocRecord completes its part of record processing
	** If newSeverity is NO_ALARM and prevSeverity ~~is not NO_ALARM~~		** If newSeverity is NO_ALARM and prevSeverity has a different value
	*** alarmSeverity is set to NO_ALARM		*** alarmSeverity is set to NO_ALARM
	*** alarmStatus is set to empty		*** alarmStatus is set to empty
Line 576:		Line 584:
	* <tt>dataStruct</tt> Each support has an associated struct for configuration.		* <tt>dataStruct</tt> Each support has an associated struct for configuration.

	How should ~~the~~ be made available? Perhaps:		How should these be made available? Perhaps:

	The field appears as a string with the following syntax:		The field appears as a string with the following syntax: