From: Edi W. <ed...@ag...> - 2004-07-20 04:05:18
|
On Tue, 20 Jul 2004 01:06:43 +0100, Daniel Barlow <da...@te...> wrote: > The CL-PPCRE thread tests seem to work quite nicely as a test of > thread creation/exiting, which had a number of exciting race > conditions. You may (and everyone else using or wanting to use > threaded SBCL may also) want to check out 0.8.12.42 which fixes at > least three of these and seems to run the threaded tests in cl-ppcre > 0.7.9 quite happily. > > This also fixes the thundering herd at thread gc rather more cleanly > than inserting sched_yields around the place: thanks to Juho > Snellman and Christophe Rhodes on #lisp for pointing this stuff out. > > So, unless Bill advises to the contrary, SBCL will shortly be going > into code-mostly-freeze for the 0.8.13 release. Therefore it would > be a really good thing if people would test their threaded stuff for > regressions /now/ instead of leaving it a week: then any bugs can be > fixed in time for this month instead of next. Cool, thanks. > (Incidentally, your threaded-scan function seems to be doing incf of > a shared variable COUNTER without the aid of a lock; this is > probably not guaranteed to work everywhere. I think it happens to > work in SBCL (if so, mostly because it happens to work on x86), but > you probably want to have some kind of atomic-incf there, or protect > it with a mutex) OK. Is there a list of what's atomic and what's not in SBCL somewhere? APROPOS says there's SB-IMPL::ATOMIC-INCF/SYMBOL but it's not exported so I guess I shouldn't use it? And, while we're at it: Is WITH-MUTEX in a native-threads SBCL semantically equivalent to, say, WITH-LOCK-HELD in CMUCL with cooperative threads or is there something to watch out for? Thanks, Edi. |