From: Nikodemus S. <nik...@ra...> - 2010-03-26 09:25:13
|
On 26 March 2010 11:00, Tobias C. Rittweiler <tc...@fr...> wrote: > I agree. I also think we ought to get rid of the name WAITQUEUE and call > it CONDITION-VARIABLE. Some possible naming ideas from the CMUCL history, see: http://www.cs.cmu.edu/afs/cs/project/clisp/hackers/wlott/work/threads.txt which contains: "Event structures can be used to synchronize multiple threads. These are just like the cthreads conditions, but name is different to keep from conflicting with Common Lisp conditions. make-event &key name Make a new event object. event-name event Return (or set) the associated name. Again, only used by the print function. event-wait event mutex Wait for some event to arise. The mutex is unlocked and the current thread is put in a :waiting state (this happens atomically). When the event is signaled, attempt to re-acquire the lock on the mutex and return. As some other thread might have beaten this thread to the lock, the condition should be verified again. For example: (with-mutex (*mutex*) (loop (if <some random condition protected by *mutex*> (return) (event-wait *mutex* *event*))) <do stuff depending on this condition>) on-event (mutex event-var) condition-form &body body [macro] Syntactic sugar for the standard way to use events. The above example becomes: (on-event (*mutex* *event*) <some random condition protected by *mutex*> <do stuff depending on this condition>) event-signal event Signal that EVENT has happened. This wakes up only one of the thread that are waiting on the event. event-broadcast event Same as event-signal, but wake up all threads waiting on the event. " > We -could- do this in the forthcoming SB-CONCURRENCY contrib. I think SB-THREAD is the right place. > Though I'm not sure about how one should describe the relation between > SB-THREADS and SB-CONCURRENCY afterwards. Now it's "Additional > thread-related datastructures and tools", i.e. an addition to > SB-THREADS. With that decision, we could also move the status of > SB-THREADS to "public but deprecated", and reexport its API in corrected > form from SB-CONCURRENCY. I see SB-CONCURRENCY as analogous to java.util.concurrent. SB-THREAD is the bare-bones stuff. SB-CONCURRENCY is data structures implemented using that bare-bones stuff. (Semaphores are in SB-THREAD along with locks and condition variables because you can implement condition variables using semaphores and vice versa -- we're not looking for an ideal minimal interface, but a reasonable set of primitives.) Cheers, -- Nikodemus |