Provides {@link ist.palcom.palcomthreads.PalcomScheduler} and {@link ist.palcom.palcomthreads.PalcomScheduler}, 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 {@link ist.palcom.palcomthreads.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 {@link ist.palcom.palcomthreads.PalcomThread} and that is where the user implements the processes he or she needs. Technically they are implemented as a method, {@link ist.palcom.palcomthreads.PalcomThread#run}, which eventually will be called by the Scheduler.

Internally, the PalcomThreads are implemented using a {@link ist.palcom.base.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 {@link ist.palcom.palcomthreads.Semaphore}.

Monitor

{@link ist.palcom.palcomthreads.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

{@link ist.palcom.palcomthreads.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 {@link ist.palcom.palcomthreads.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 {@link ist.palcom.palcomthreads.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 {@link ist.palcom.palcomthreads.PalcomScheduler}. These pre-defined subclasses are used to communicate events from the PalcomScheduler to the PalcomThreads.