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 _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
