[PEAK] Sync, async, loops, and threads

Phillip J. Eby pje at telecommunity.com
Mon Jan 19 09:52:31 EST 2004


At 11:49 AM 1/19/04 +0100, Dominikus Herzberg wrote:

>View the "world" as independent processes with explicit Message
>Exchange Points (MEPs) for input and output. You can interconnect
>processes at their input/output MEPs. You can now specify in very
>much detail how message passing is done. For example, process A
>passes a message to its outMEP but remains blocked until process B
>returns with its thread of control to the inMEP. This behavior
>emulates a single thread of control although we have multiple
>independent processes.
>
>I think you get the point. With this model you can simulate asynch
>and synch communication, single or multiple threads of control and
>more (see also slide 21 on functional spheres). The fun part is
>that you can easily intermingle various communication and execution
>paradigms.
>
>I am thinking about developing a framework that uses this simple
>process and interaction model as a basis. I would then introduce
>a scheduler (of course), which controls execution and permits
>changes to the execution model.

You might want to take a look at what's already implemented so far in the 
'peak.events' package, which includes ultralight threads that transfer 
control to one another based on communication points known as "event 
sources" that control task switching as well as communication of data.  For 
example a 'Distributor' event source can be waited on by multiple 
pseudothreads, and each value sent to the distributor will be given to the 
next available thread.  A 'Broadcaster', on the other hand, will send each 
value it is given to all waiting threads.  This is all working and tested, 
incuding time, signal, and I/O scheduling.  (Actually, I/O scheduling and 
signal handling aren't throroughly tested yet, but time scheduling, threads 
and communication between them are heavily tested.)

A good place to start is peak.events.interfaces, which describes the 
concepts and expected interfaces between them.  Then peak.events.sources 
and peak.events.event_threads are pretty straightforward implementations of 
them.




More information about the PEAK mailing list