[Gardeners] Shared State Concurrency specification.

[Marco Monteiro]

Hello, Gregory.

I do know Bordeaux-Threads. The purpose of the SSC project is to build a
thread model specification, programming interface documentation and a 
test suite. In addition, I'm working on an implementation of the SSC 
Specification in SBCL. Although it will probably be done, the main 
purpose is not to build a wrapping library for CL implementations. There 
are too many differences between the implementations for an approach 
like that to work well.

In a year or two, all computers sold will have two or more processing 
units. There should be a standard CL API to access thread functionality, 
with standard semantics, equal in all implementations.

What I'm proposing is not very innovative. Actually, as it is right now, 
it is almost POSIX threads for CL. The advantage is that it will not be 
very messed up. I hope that more people, mainly implementors of CL, will 
help in the future, as the specification gets tidy up. It is very 
important that we get this right.

I'm open to all suggestion regarding the API to approximate it to what 
exists in Bordeaux-Threads; maybe change LOCK-MUTEX and UNLOCK-MUTEX to 
ACQUIRE-LOCK and RELEASE-LOCK, for instance. Maybe we can work together 
to merge our efforts, although we are not working with the same objective.

Gregory Martin Pfeil wrote:
> Searching for "shared state concurrency" on Cliki returns some  
> results (http://www.cliki.net/admin/search?words=shared-state 
> +concurrency), the notable one being Bordeaux-Threads (http://common- 
> lisp.net/project/bordeaux-threads/). While I've only taken a quick  
> glance at your PDF, it seems to have a lot of the same functionality  
> with some higher-level functionality that can be built on top of the  
> lower stuff. Why not build on top of Bordeaux-Threads? It already  
> works in six+ implementations, so gives you a portable layer to build  
> the counting semaphores, cyclic barriers, and thread-mailbox on top of.

Semaphores and cyclic barriers can be implemented more efficiently if 
they are in the implementation. In my SBCL implementation, for instance, 
semaphores are several time faster than if they were built on mutexes 
and condition variables. Synchronization primitives should be very 
efficient.

Thread mailboxes will not be in SSC; I'm still thinking how to allow 
extensions to build them; I need thread specific storage accessible 
outside the implementation, maybe. But this is something that is not 
fundamentally required, as we have local bindings of special variables.
There are many things still to be done.

I hope to hear from you.

Cheers,

Marco