|
|||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES | ||||||||
PalcomScheduler and PalcomThread, which can be used for
implementing concurrency in PalCom applications.
See:
Description
| Class Summary | |
|---|---|
| Event | |
| IOAvailableEvent | Sent as result of call to enableIOTimeoutEvent when input is available. |
| IOTimeoutEvent | Sent as result of call to enableIOTimeoutEvent when no input has become available for timeout milliseconds. |
| Mailbox | |
| Monitor | |
| PalcomPriorityThread | |
| PalcomScheduler | |
| PalcomThread | |
| PeriodicEvent | Sent as result of call to enablePeriodicEvents every period milliseconds. |
| Semaphore | |
Provides PalcomScheduler and PalcomThread, which can be used for
implementing concurrency in PalCom applications.
The most important classes in this package are the following:
PalcomScheduler which
implements a scheduler
PalcomThread for user threads
Schedulers are responsible for giving CPU time to the user-defined
threads and to take care of the situation when there is nothing to
do among the threads it handles. In the simple case there is only
one object of the PalcomScheduler
class, which the user needs (typically in the main program) to
create, and give control to. The default scheduler implementation
uses a common priority system to schedule processes. This can be
used to give more attention to threads with shorter time-demands.
The system is designed for later extensions so it can actually handle hierarchical systems of schedulers.
This framework comes with a default scheduler, but it is possible for the advanced user to implement and use his own scheduler, for example using another scheduling scheme.
The user defines sub-classes of PalcomThread and that is where the user
implements the processes he or she needs. Technically they are
implemented as a method, PalcomThread.run(), which eventually will be
called by the Scheduler.
Internally, the PalcomThreads are implemented using a Coroutine. The PalcomScheduler attaches one
coroutine at a time, and lets it run until it suspends itself
(cooperative scheduling; preemptive scheduling is possible with this
scheme, but not yet implemented).
For communication between the user-defined threads there are three common synchronization mechanisms available.
The semaphore is a simple mechanism that can be used for mutual
exclusion or signalling. Simple as it is it should be used with care
since it is a bit low-level for most situations. It is normally used
by creating objects directly of the class Semaphore.
Monitor is a more high-level
synchronization mechanism that combines mutual exclusion and
signalling in one construct. It is often very practical to use when
synchronization depends on data or datastructures that can be
inspected and updated by several processes. The user makes
subclasses of this class and operations on instances of these
classes, becomes mutually excluded.
Mailbox is also a high-level
synchronization mechanism that typically used for communication of
data, or "events" from one process (producer) to the another
(consumer). Typically the construct is also used for signalling so
the consumer is delayed until data is available. Every UserProcess
has a mailbox which is used for events to the process from the
Scheduler as well as events to it from other processes. A Mailbox is
technically a bounded FIFO buffer with synchronized operations for
inserting and removing messages.
The messages sent to a Mailbox are subclasses of a common class
Event. In
some situations it is practical to include data in such a class,
which is thus communicated to the Consumer process, and in other
situations the information is simply signalling the occurrence of an
Event itself in which case an empty
event is sufficient. The user can create new such subclasses and
there are a number of subclasses defined by the PalcomScheduler. These pre-defined
subclasses are used to communicate events from the PalcomScheduler
to the PalcomThreads.
|
|||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES | ||||||||