Thread

Thread provides a collection of objects for the purpose of building multithreaded applications. The following objects are included;

• VJob
• VThread
• VArbiter
• VClock
• VApp

The simplest thread group object is VJob. The VJob is a thread without a message queue. It would normally be launched from another thread, do it's work concurrently, and post the results back to the calling thread. In practice a job can post it's result back to any object associated with a thread that has a message queue. A VJob cannot create a child VJob unless the child VJob posts it's result to a grandparent or possibly an uncle.

The VThread object is a thread with a message queue. It is VJob derived. It may spawn a VJob and receive the results of any VJob directly. Clearly VThreads can post messages to other VThreads in the normal way.

The VArbiter is an object that aids interface between VThreads. It provides a scheme whereby a programmer may implement a subclass to create an interface. The interface targets a given VThread, which is designed to work with the arbiter by means of messages. The interface allows a caller in any thread to call by function and receive results from the call, on completion of the call. VArbiter handles all of the blocking, message passing and marshalling.

Threads work more efficiently when they operate truly synchronously. VClock is a special standalone thread which is not VJob derived and does not have a message queue. VClock posts tick messages at regular intervals to threads. It is not integral. It will not saturate the system with ticks if the system runs out of CPU cycles. Drawing on the concept of concurrent languages, clock allows the construction of a true synchronous pipelined architecture, where the minimum interval between ticks is that of the longest section of the pipeline.

Arbiter and clock represent two distinct approaches to concurrent programming. Typically arbiter is the top down approach, and clock is the bottom up approach. Both have merits and pitfalls. The arbiter approach is generally asynchronous with the concept of a "foreground" and an interface with the "background". The clock approach is generally synchronous with a pipeline of partially completed stages of calculation, each on a different thread. Completed results emerge from the end of the pipe. A number of overall calculations occur in parallel, with a calculation latency.