> Concurrency is for better or worse something which has wide-reaching > implications on all aspects of a system, but is not standardized in > any reasonable format for CL. Just a quick example - should accessing > a lexical variable be atomic? What about from a closure? Is hash > table reading atomic? Writing? About the only standard I know of for > CL concurrency (CLIM 2's MP) does not cover these issues at all.
There seems to be reasonable answers to those that I would hope most threaded lisps would satisfy. To take your examples: Access of a lexical variable: The binding itself? I would fully expect such bindings not to be guaranteed thread-safe (such as with normal pointer assignments in most languages, like C). Hashtables: There is no reason to assume it would be safe IMO. Any hashtable using mutex locking to attain thread-safety is going to be unneccessarily slow in the common case of non-concurrent access. IMO it is not the job of every single little class/type to be thread-safe in and of itself. What I *WOULD* expect in a decent environment is that concurrent read-only access to things be safe unless explicitly documented to the contrary. (I have ran into cases where this is not the case so I realize it is not a given in practice; but in an environment properly designed for concurrency I think it should be (witness e.g. Java)). > It would be an interesting experiment to run Alan Shields' Araneida > benchmark against the five supported threaded Araneida backends. I > know that Gabor Melis has been assiduously working on making it > reliable on threaded SBCL. I would guess that most of those other > backends would have at least one stability issue too, judging from > the variety of issues that this benchmark has exposed on SBCL. > Perhaps the ABCL backend does not, though - Java takes a very heavy- > weight approach to object locking, and it's my guess that the threads > have been pounded on enough to work out any rare gc or interrupt- > safety kinks. In the JVM? I would be *massively* surprised if Araneida is unstable because of problems in the JVM threading implementation. To the best of my knowledge I have never ever ran into a threading related problem in Java (other than bugs in application code). It all just works, being designed for threading from the start... at least that is my impression. -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
