From: Edi W. <ed...@ag...> - 2004-07-09 22:40:49
|
Hi! What's the status of native thread support in SBCL? Is this still seen as an experimental feature or is it deemed to be production-ready? Is someone using it in earnest? I'm asking because I'm interested in switching an existing app from CMUCL to SBCL which currently uses CMUCL's x86 threads and DB access via FFI (CLSQL). I'm hoping that the app will scale better with SBCL because FFI calls won't have the potential to block other threads. FWIW, I just tried the threaded CL-PPCRE tests again (I had an email exchange with Cristophe about this some months ago) and they still fail with SBCL 0.8.12 on Debian unstable. (Kernel is 2.6.6.) They run fine with Lispworks' green threads and they used to run fine with Scieneer's native threads when I had access to their 1.1 trial version. Thanks, Edi. |
From: David L. <da...@li...> - 2004-07-09 23:10:26
|
Quoting Edi Weitz (ed...@ag...): > What's the status of native thread support in SBCL? Is this still seen > as an experimental feature or is it deemed to be production-ready? Is > someone using it in earnest? (Don't know.) But there appears to be a problem with garbage collection that I asked about earlier: If my test is right, GC time is proportional to the total number of threads. My guess is that this behaviour was introduced in late 2003 together with all the thread stability improvements, but I have not tried to pinpoint the exact version yet. d. |
From: Julian S. <der...@we...> - 2004-07-12 21:14:45
|
Edi Weitz <ed...@ag...> writes: > What's the status of native thread support in SBCL? Is this still seen > as an experimental feature or is it deemed to be production-ready? Is > someone using it in earnest? And most importantly: Is there any work into the direction of having threads on FreeBSD? Regards, -- Julian Stecklina Signed/encrypted mail welcome. Key-ID: 0xD65B2AB5 -> GIVE stylish confetti to HEAVILY ARMED CLOWN <- -> Heavily Armed Clown: Wheeee!! <- |
From: Daniel B. <da...@te...> - 2004-07-20 00:07:14
|
Edi Weitz <ed...@ag...> writes: > FWIW, I just tried the threaded CL-PPCRE tests again (I had an email > exchange with Cristophe about this some months ago) and they still > fail with SBCL 0.8.12 on Debian unstable. (Kernel is 2.6.6.) They run > fine with Lispworks' green threads and they used to run fine with > Scieneer's native threads when I had access to their 1.1 trial > version. 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. (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) -dan -- "please make sure that the person is your friend before you confirm" |
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. |
From: Daniel B. <da...@te...> - 2004-08-20 22:27:03
|
I've had this message marked in Gnus for ages and can't remember having replied to it before. So - Edi Weitz <ed...@ag...> writes: > OK. Is there a list of what's atomic and what's not in SBCL somewhere? No, but the short answer is probably "not a lot". Atomic: SETF on places that you would reasonably expect are implemented under the hood as stores into word-sized slots. Less liely to be atomic: all else. In particular (people often ask about this one), (setf gethash) is not atomic and not likely to be unless there suddenly turns out to be some way to make it so without adding overhead. Hmm. That's one to add to the manual, actually. I don't know what other implementations do. Of course, lisp-scheduled implementations quite possibly only context-switch on fairly coarse boundaries anyway, which may make the problem less pressing. > APROPOS says there's SB-IMPL::ATOMIC-INCF/SYMBOL but it's not exported > so I guess I shouldn't use it? I'd forgotten it was there, for one thing. It won't go away until I think of something better, but I'd dearly love to do so. > 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? I can't remember if WITH-LOCK-HELD allows for recursive locks, but wither WITH-MUTEX or WITH-RECURSIVE-LOCK (hmm, why the naming asymmetry?) should do the trick, depending. This may be a good time to point out also that SBCL 0.8.14 will have (and current CVS already has) slightly better threading documentation than previous versions. Whether it also has reliable INTERRUPT-THREAD is another matter; my guess is "no", unless I come up with some good idea in the very near future. Issues explained at http://ww.telent.net/diary/2004/8/#20.47485 if anyone feels like thinking about it further. -dan -- "please make sure that the person is your friend before you confirm" |