Lib/sequencer offers Multitasking - Revision history

Hzwakenberg at 12:28, 30 July 2024

2024-07-30T12:28:00Z

← Older revision		Revision as of 14:28, 30 July 2024
Line 24:		Line 24:

	# <tt>prepare</tt> allows preparing the task; in this phase, the task sets the events upon which it wants to be activated. The [[library_class:EVENTS_SET\|<tt>EVENTS_SET</tt>]] object is an object upon which one can set conditions (thanks to its <tt>expect</tt> feature).		# <tt>prepare</tt> allows preparing the task; in this phase, the task sets the events upon which it wants to be activated. The [[library_class:EVENTS_SET\|<tt>EVENTS_SET</tt>]] object is an object upon which one can set conditions (thanks to its <tt>expect</tt> feature).
−	# <tt>is_ready</tt> allows ~~to test~~ if the task has really been activated. The [[library_class:EVENTS_SET\|<tt>EVENTS_SET</tt>]] object is an object upon which one can test conditions (thanks to its <tt>event_occurred</tt> feature).	+	# <tt>is_ready</tt> allows testing if the task has really been activated. The [[library_class:EVENTS_SET\|<tt>EVENTS_SET</tt>]] object is an object upon which one can test conditions (thanks to its <tt>event_occurred</tt> feature).
	# <tt>continue</tt> contains the execution body of the task, and is executed upon task activation.		# <tt>continue</tt> contains the execution body of the task, and is executed upon task activation.
	# <tt>done</tt> tells if the task has finished its execution. If so, it will be removed from the execution loop. Otherwise, the cycle begins again.		# <tt>done</tt> tells if the task has finished its execution. If so, it will be removed from the execution loop. Otherwise, the cycle begins again.
Line 33:		Line 33:
	== Execution conditions ==		== Execution conditions ==

−	The class [[library_class:EVENTS_SET\|<tt>EVENTS_SET</tt>]] allows ~~to set~~ and test conditions ([[library_class:EVENT_DESCRIPTOR\|<tt>EVENT_DESCRIPTOR</tt>]]s).	+	The class [[library_class:EVENTS_SET\|<tt>EVENTS_SET</tt>]] allows setting and test conditions ([[library_class:EVENT_DESCRIPTOR\|<tt>EVENT_DESCRIPTOR</tt>]]s).

	The possible conditions are:		The possible conditions are:

Hzwakenberg at 11:25, 1 January 2022

2022-01-01T11:25:57Z

← Older revision		Revision as of 13:25, 1 January 2022
Line 2:		Line 2:
	The <tt>lib/sequencer</tt> library implements an event-driven, priority-based, cooperative multitasker. The sequencer library does not start new threads or any other separate processes. Unlike "pure" cooperative multitasking, a task cannot stop at any time (using a hypothetical <tt>yield</tt> feature) but only in known and stable states. The sequencer library does it this way to retain conformance to Eiffel principles.		The <tt>lib/sequencer</tt> library implements an event-driven, priority-based, cooperative multitasker. The sequencer library does not start new threads or any other separate processes. Unlike "pure" cooperative multitasking, a task cannot stop at any time (using a hypothetical <tt>yield</tt> feature) but only in known and stable states. The sequencer library does it this way to retain conformance to Eiffel principles.

		+	The sequencer library concepts:
−	The principles are:

	* the class [[library_class:LOOP_STACK\|<tt>LOOP_STACK</tt>]] manages the multitasking;		* the class [[library_class:LOOP_STACK\|<tt>LOOP_STACK</tt>]] manages the multitasking;

Hzwakenberg: Lingual corrections

2022-01-01T11:24:40Z

Lingual corrections

← Older revision		Revision as of 13:24, 1 January 2022
Line 1:		Line 1:
	[[Category: Library]]		[[Category: Library]]
−	The <tt>lib/sequencer</tt> library implements an event-driven, priority-based, cooperative multitasker. The sequencer library does not start new threads or any other separate processes. Unlike "pure" cooperative multitasking, a task cannot stop at any time (using a hypothetical <tt>yield</tt> feature) but only in known and stable states. The sequencer library does it this way to retain conformance to ~~the~~ Eiffel principles.	+	The <tt>lib/sequencer</tt> library implements an event-driven, priority-based, cooperative multitasker. The sequencer library does not start new threads or any other separate processes. Unlike "pure" cooperative multitasking, a task cannot stop at any time (using a hypothetical <tt>yield</tt> feature) but only in known and stable states. The sequencer library does it this way to retain conformance to Eiffel principles.

−	The ~~principle~~ is:	+	The principles are:

	* the class [[library_class:LOOP_STACK\|<tt>LOOP_STACK</tt>]] manages the multitasking;		* the class [[library_class:LOOP_STACK\|<tt>LOOP_STACK</tt>]] manages the multitasking;
Line 8:		Line 8:
	* the class [[library_class:EVENTS_SET\|<tt>EVENTS_SET</tt>]] describes the condition(s) in which a task can be executed.		* the class [[library_class:EVENTS_SET\|<tt>EVENTS_SET</tt>]] describes the condition(s) in which a task can be executed.

−	We will successively document each of ~~those~~ concepts:	+	We will successively document each of these concepts:

	== The multitasking manager ==		== The multitasking manager ==
Line 17:		Line 17:
	Of course, additional tasks can be added during the execution. The manager can also be stopped, thanks to the <tt>break</tt> feature.		Of course, additional tasks can be added during the execution. The manager can also be stopped, thanks to the <tt>break</tt> feature.

−	Note that the ~~loops~~ stack ~~is composed of~~ many execution loops ([[library_class:LOOP_ITEM\|<tt>LOOP_ITEM</tt>]]). This allows, for instance, the implementation of a kind of ''modality'' (e.g. the modal windows in [[lib/vision\|Vision]]).	+	Note that the loop stack contains many execution loops ([[library_class:LOOP_ITEM\|<tt>LOOP_ITEM</tt>]]). This allows, for instance, the implementation of a kind of ''modality'' (e.g. the modal windows in [[lib/vision\|Vision]]).

	== Tasks ==		== Tasks ==
Line 23:		Line 23:
	A task has a life cycle represented by the features executed by the manager (indeed a [[library_class:LOOP_ITEM\|<tt>LOOP_ITEM</tt>]] hence the export clauses of those features).		A task has a life cycle represented by the features executed by the manager (indeed a [[library_class:LOOP_ITEM\|<tt>LOOP_ITEM</tt>]] hence the export clauses of those features).

−	# <tt>prepare</tt> allows ~~to prepare~~ the task; in this phase, the task sets the events upon which it wants to be activated. The [[library_class:EVENTS_SET\|<tt>EVENTS_SET</tt>]] object is an object upon which one can set conditions (thanks to its <tt>expect</tt> feature).	+	# <tt>prepare</tt> allows preparing the task; in this phase, the task sets the events upon which it wants to be activated. The [[library_class:EVENTS_SET\|<tt>EVENTS_SET</tt>]] object is an object upon which one can set conditions (thanks to its <tt>expect</tt> feature).
−	# <tt>is_ready</tt> allows to test if the task has really been activated.The [[library_class:EVENTS_SET\|<tt>EVENTS_SET</tt>]] object is an object upon which one can test conditions (thanks to its <tt>event_occurred</tt> feature).	+	# <tt>is_ready</tt> allows to test if the task has really been activated. The [[library_class:EVENTS_SET\|<tt>EVENTS_SET</tt>]] object is an object upon which one can test conditions (thanks to its <tt>event_occurred</tt> feature).
−	# <tt>continue</tt> contains the execution body of the task, and is executed ~~if the~~ task ~~is really activated~~.	+	# <tt>continue</tt> contains the execution body of the task, and is executed upon task activation.
	# <tt>done</tt> tells if the task has finished its execution. If so, it will be removed from the execution loop. Otherwise, the cycle begins again.		# <tt>done</tt> tells if the task has finished its execution. If so, it will be removed from the execution loop. Otherwise, the cycle begins again.
−	# <tt>restart</tt> allows ~~to reinsert~~ a task in the execution loop.	+	# <tt>restart</tt> allows reinserting a task in the execution loop.

	The <tt>restart</tt> feature is seldom useful. See [[lib/vision\|Vision]] for some use cases.		The <tt>restart</tt> feature is seldom useful. See [[lib/vision\|Vision]] for some use cases.
Line 57:		Line 57:
	== Priorities ==		== Priorities ==

−	Tasks ~~are~~ ~~executed~~ by priority order. Only the ready task with the ''lowest'' priority is executed. ~~The~~ ~~others~~, even if ready, will have to wait ~~a future time when~~ no other task with a lower priority is ready.	+	Tasks execution is by priority order. Only the ready task with the ''lowest'' priority is executed. All other tasks, even if ready, will have to wait until no other task with a lower priority is ready.

	-note: we need to document how many priority levels <br> are supported and how the scheduling works when multiple or all tasks were given<br> an identical priority level. Would the scheduler then resort to some sort<br> of round-robin method? By what rules? Apparently '''not''' by evaluating the duration of the<br> wait for next execution, see the '''LOOP_ITEM.run''' method. /HZ		-note: we need to document how many priority levels <br> are supported and how the scheduling works when multiple or all tasks were given<br> an identical priority level. Would the scheduler then resort to some sort<br> of round-robin method? By what rules? Apparently '''not''' by evaluating the duration of the<br> wait for next execution, see the '''LOOP_ITEM.run''' method. /HZ
Line 63:		Line 63:
	== Libraries using the sequencer ==		== Libraries using the sequencer ==

−	* [[lib/net]]: servers usually allow ~~to accept~~ many simultaneous connections. This is implemented with the sequencer library.	+	* [[lib/net]]: servers usually allow many simultaneous connections. This is implemented with the sequencer library.

	* [[lib/vision]]: the event manager loop is implemented with a sequencer.		* [[lib/vision]]: the event manager loop is implemented with a sequencer.

Hzwakenberg at 07:20, 16 June 2016

2016-06-16T07:20:39Z

← Older revision		Revision as of 09:20, 16 June 2016
Line 59:		Line 59:
	Tasks are executed by priority order. Only the ready task with the ''lowest'' priority is executed. The others, even if ready, will have to wait a future time when no other task with a lower priority is ready.		Tasks are executed by priority order. Only the ready task with the ''lowest'' priority is executed. The others, even if ready, will have to wait a future time when no other task with a lower priority is ready.

−	-note: we need to document how many priority levels <br> are supported and how the scheduling works when multiple or all tasks were given<br> an identical priority level. Would the scheduler then resort to some sort<br> of round-robin method? By what rules? ~~Perhaps~~ by evaluating the duration of the<br> wait for next execution~~? Also~~ see the '''LOOP_ITEM.run''' method. /HZ	+	-note: we need to document how many priority levels <br> are supported and how the scheduling works when multiple or all tasks were given<br> an identical priority level. Would the scheduler then resort to some sort<br> of round-robin method? By what rules? Apparently '''not''' by evaluating the duration of the<br> wait for next execution, see the '''LOOP_ITEM.run''' method. /HZ

	== Libraries using the sequencer ==		== Libraries using the sequencer ==

Hzwakenberg at 07:19, 16 June 2016

2016-06-16T07:19:18Z

← Older revision		Revision as of 09:19, 16 June 2016
Line 59:		Line 59:
	Tasks are executed by priority order. Only the ready task with the ''lowest'' priority is executed. The others, even if ready, will have to wait a future time when no other task with a lower priority is ready.		Tasks are executed by priority order. Only the ready task with the ''lowest'' priority is executed. The others, even if ready, will have to wait a future time when no other task with a lower priority is ready.

−	-note: we need to document how many priority levels <br> are supported and how the scheduling works when multiple or all tasks were given<br> an identical priority level. Would the scheduler then resort to some sort<br> of round-robin method? By what rules? Perhaps by evaluating the ~~<br>~~duration of the wait for next execution? Also see the '''LOOP_ITEM.run''' method. /HZ	+	-note: we need to document how many priority levels <br> are supported and how the scheduling works when multiple or all tasks were given<br> an identical priority level. Would the scheduler then resort to some sort<br> of round-robin method? By what rules? Perhaps by evaluating the duration of the<br> wait for next execution? Also see the '''LOOP_ITEM.run''' method. /HZ

	== Libraries using the sequencer ==		== Libraries using the sequencer ==

Hzwakenberg at 07:17, 16 June 2016

2016-06-16T07:17:53Z

← Older revision		Revision as of 09:17, 16 June 2016
Line 59:		Line 59:
	Tasks are executed by priority order. Only the ready task with the ''lowest'' priority is executed. The others, even if ready, will have to wait a future time when no other task with a lower priority is ready.		Tasks are executed by priority order. Only the ready task with the ''lowest'' priority is executed. The others, even if ready, will have to wait a future time when no other task with a lower priority is ready.

−	-note: we need to document how many priority levels <br> are supported and how the scheduling works when multiple or all tasks were given<br> an identical priority level. Would the scheduler then resort to some sort<br> of round-robin method? By what rules? Perhaps by evaluating the duration of the wait for next execution? /HZ	+	-note: we need to document how many priority levels <br> are supported and how the scheduling works when multiple or all tasks were given<br> an identical priority level. Would the scheduler then resort to some sort<br> of round-robin method? By what rules? Perhaps by evaluating the <br>duration of the wait for next execution? Also see the '''LOOP_ITEM.run''' method. /HZ

	== Libraries using the sequencer ==		== Libraries using the sequencer ==

Hzwakenberg: /* Priorities */

2016-06-16T07:09:45Z

Priorities

← Older revision		Revision as of 09:09, 16 June 2016
Line 57:		Line 57:
	== Priorities ==		== Priorities ==

−	Tasks are executed by priority order. Only the ready ~~tasks~~ with a ''~~lower~~'' priority ~~are~~ executed. The others, even if ready, will have to wait a future time when no other task with a lower priority is ready.	+	Tasks are executed by priority order. Only the ready task with the ''lowest'' priority is executed. The others, even if ready, will have to wait a future time when no other task with a lower priority is ready.

−	-note: we need to document how many priority levels <br> are supported and how the scheduling works when multiple or all tasks were given<br> an identical priority level. Would the scheduler then resort to some sort<br> of round-robin method? By what rules? /HZ	+	-note: we need to document how many priority levels <br> are supported and how the scheduling works when multiple or all tasks were given<br> an identical priority level. Would the scheduler then resort to some sort<br> of round-robin method? By what rules? Perhaps by evaluating the duration of the wait for next execution? /HZ

	== Libraries using the sequencer ==		== Libraries using the sequencer ==

Hzwakenberg: Hzwakenberg moved page Lib/sequencer to Lib/sequencer offers Multitasking

2016-06-15T18:51:26Z

Hzwakenberg moved page Lib/sequencer to Lib/sequencer offers Multitasking

← Older revision	Revision as of 20:51, 15 June 2016
(No difference)

Hzwakenberg at 18:50, 15 June 2016

2016-06-15T18:50:53Z

← Older revision		Revision as of 20:50, 15 June 2016
Line 1:		Line 1:
	[[Category: Library]]		[[Category: Library]]
−	The <tt>lib/sequencer</tt> library implements an event-driven ~~cooperative~~ priority-based multitasker. The sequencer library does not start new threads or any other separate processes. Unlike "pure" cooperative ~~multi-tasking~~, a task cannot stop at any time (using a hypothetical <tt>yield</tt> feature) but only in known and stable states. ~~That~~ is ~~conforming~~ to the Eiffel principles.	+	The <tt>lib/sequencer</tt> library implements an event-driven, priority-based, cooperative multitasker. The sequencer library does not start new threads or any other separate processes. Unlike "pure" cooperative multitasking, a task cannot stop at any time (using a hypothetical <tt>yield</tt> feature) but only in known and stable states. The sequencer library does it this way to retain conformance to the Eiffel principles.

	The principle is:		The principle is:

−	* the class [[library_class:LOOP_STACK\|<tt>LOOP_STACK</tt>]] manages the ~~multi-tasking~~;	+	* the class [[library_class:LOOP_STACK\|<tt>LOOP_STACK</tt>]] manages the multitasking;
	* the class [[library_class:JOB\|<tt>JOB</TT>]] represents a task. The task core is the <tt>continue</tt> feature, during the execution of which the task controls the whole system;		* the class [[library_class:JOB\|<tt>JOB</TT>]] represents a task. The task core is the <tt>continue</tt> feature, during the execution of which the task controls the whole system;
	* the class [[library_class:EVENTS_SET\|<tt>EVENTS_SET</tt>]] describes the condition(s) in which a task can be executed.		* the class [[library_class:EVENTS_SET\|<tt>EVENTS_SET</tt>]] describes the condition(s) in which a task can be executed.
Line 10:		Line 10:
	We will successively document each of those concepts:		We will successively document each of those concepts:

−	== The ~~multi-tasking~~ manager ==	+	== The multitasking manager ==
−	The class [[library_class:LOOP_STACK\|<tt>LOOP_STACK</tt>]] is in charge of managing the ~~multi-tasking~~. It is used in two steps:	+	The class [[library_class:LOOP_STACK\|<tt>LOOP_STACK</tt>]] is in charge of managing the multitasking. It is used in two steps:
	* initialization: creation of the <tt>LOOP_STACK</tt> object and adding the task(s) to be executed		* initialization: creation of the <tt>LOOP_STACK</tt> object and adding the task(s) to be executed
	* execution: execution of the <tt>run</tt> feature		* execution: execution of the <tt>run</tt> feature

Hzwakenberg at 18:44, 15 June 2016

2016-06-15T18:44:25Z

← Older revision		Revision as of 20:44, 15 June 2016
Line 12:		Line 12:
	== The multi-tasking manager ==		== The multi-tasking manager ==
	The class [[library_class:LOOP_STACK\|<tt>LOOP_STACK</tt>]] is in charge of managing the multi-tasking. It is used in two steps:		The class [[library_class:LOOP_STACK\|<tt>LOOP_STACK</tt>]] is in charge of managing the multi-tasking. It is used in two steps:
−	* initialization: creation of the <tt>LOOP_STACK</tt> object, and adding the ~~tasks~~ to be executed	+	* initialization: creation of the <tt>LOOP_STACK</tt> object and adding the task(s) to be executed
	* execution: execution of the <tt>run</tt> feature		* execution: execution of the <tt>run</tt> feature

−	Of course, tasks can be added during the execution. The manager can also be stopped, thanks to the <tt>break</tt> feature.	+	Of course, additional tasks can be added during the execution. The manager can also be stopped, thanks to the <tt>break</tt> feature.

−	~~Also,~~ the loops stack is composed of many execution loops ([[library_class:LOOP_ITEM\|<tt>LOOP_ITEM</tt>]]). This allows, for instance, the implementation of a kind of ''modality'' (e.g. the modal windows in [[lib/vision\|Vision]]).	+	Note that the loops stack is composed of many execution loops ([[library_class:LOOP_ITEM\|<tt>LOOP_ITEM</tt>]]). This allows, for instance, the implementation of a kind of ''modality'' (e.g. the modal windows in [[lib/vision\|Vision]]).

	== Tasks ==		== Tasks ==