From: Kaz K. <kky...@gm...> - 2009-02-03 23:39:56
|
[ This has been sitting forgotten in my Drafts folder ] On Wed, Jan 28, 2009 at 7:35 AM, Sam Steingold <sd...@gn...> wrote: > Kaz Kylheku wrote: >> >> On Mon, Jan 26, 2009 at 3:33 PM, Sam Steingold <sd...@gn...> wrote: >> This kind of operation, though seemingly useful on the surface, is not >> useful in robust multithreaded programming. >> >> The question is, what are you going to do with them. Their use is >> fraught with race conditions. By the time you make any decision based >> on whether a thread is sleeping or not, that state could have changed. > > why do other cl implementations offer this function? > some even make it SETFable! I would say that it's because their designs and implementations are heavily outdated, going back to the dark ages before there was more wide spread awareness about good system designs for multithreading, and good practices at the application level. Come on, the threading models in some Lisps are just ridiculous and primitive. Where in POSIX or Win32 can you call to find out these thread states? On Linux, this function would have to open virtual files under /proc/<pid>. > http://www.scieneer.com/scl/doc/function/mp/process-whostate.html > http://www.franz.com/support/documentation/6.0/doc/pages/operators/mp/process-whostate.htm > http://www.lispworks.com/documentation/lw51/LWRM/html/lwref-449.htm This is all bad, outdated multithreading that tries to maintain compability between two threading models (the real OS threads and fake ones) by building silly cruft on top of the OS threads that does not make sense. For instance, take a look at the process-wait function supported in these Lisps. The purpose is to suspend a thread until some predicate becomes true. Anyone who knows anything about sane multithreading will immediately recognize this kind of interface being out of place under preemptive multitasking or multiprocessing. It's a throwback to cooperative multitasking. There is no correct way to use this function if threads are preemptive, or truly concurrent on multiple processors, because the calling thread does not hold any lock that can preserve the truth value of the predicate, or ensure that the wakeup from another thread is not lost. It is like a condition variable wait, but without the mutex to resolve races. C. A. R. Hoare invented the concept of waiting until a condition happens, i.e. the same thing as process-wait. He described it in a 1974 paper called _Monitors: an operating system structuring concept_ To do the equivalent of process-wait, you have to be in a monitor, which is implicitly given up during the wait. These guys didn't read the paper. Or maybe their implementations even pre-date 1974. LispWorks does implement the monitor erquirement. How? By not allowing any real concurrency. Come on, the 1970's are calling and want their multithreading back. Housewives now have multi-core laptop computers that they use for sharing recipes. :) Please, don't copy any of this braindamage in CLISP. If a compatibility layer is desireable for porting applications that depend on the threading models in these Lisps, that can be done as a separate API project. All of the threads using such an API can be made cooperative relative to just each other each other (by locking a big mutex). |