Package ist.palcom.palcomthreads

Provides 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  
 

Package ist.palcom.palcomthreads Description

Provides PalcomScheduler and PalcomThread, which can be used for implementing concurrency in PalCom applications.

Package Specification

The most important classes in this package are the following:

Schedulers

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.

User-defined Threads

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).

Synchronization classes

For communication between the user-defined threads there are three common synchronization mechanisms available.

Semaphore

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

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.

Mailboxes

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.

Event classes

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.