-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [EMAIL PROTECTED] (Gerd Moellmann) writes:
> One thing one could do is store with each symbol, when it gets a > thread-local binding, an offset in thread-local storage where its > value cell is found. Maybe there also has to be some code that > determines if a symbol has a thread-local binding to start with, > dunno. But I think the picture is not that bad overall; slower by > some constant factor should be possible, I think. Yes, yes, and yes. This is what SBCL does; also Corman, I think, and probably SCL (I know dtc was experimenting with it in CMUCL prior to starting work on Scieneer CL). I added a tl-value-offset slot to the symbol, which is an offset into the thread-local storage area. This could be indexed using a normal register on a machine that had any, but as there basically are no such things on x86 we use the %fs segment selector instead. This gets initialised to zero when a new symbol is consed; because I'm lazy I stick the unbound-symbol-value marker in at the beginnning of TLS, so we don't have to write two tests on each symbol access Not that it might not be a bad idea anyway to save a memory access, given that the tls area is almost page-aligned so probably not very likely to stay in cache for any length of time, but I've not had the inclination to monkey around with it yet. Besides, does anyone _really_ do special variable lookups in performance-critical code? There are bigger performance fish to fry in SBCL ... We were using %gs, but newer versions of the gnu c library want %gs for NPTL thread-local storage and i didn;'t really want to tangle with that. The glibc people _presumably_ have to keep their ahnds off %fs, because Wine needs it for running Windows code As to the current state of threads in SBCL, they went in to CVS HEAD a couple of months ago and are in the released 0.8.0, but not in the default build. But hey, rebuuilding is easy ;-) They basically work, but for (a) rough edges. TODO list at http://sbcl-internals.cliki.net/Threading (b) there may be a bug somewhere in the locking code. Only ever exposed so far in McCLIM; could equally well be a CLX bug but it's not obvious how if so. (c) UI is a bit primitive in places (although much better if you use the sb-aclrepl contrib package) (d) we share one of the the basic problems with CMUCL threads: the library is not terribly threadsafe. We stuck great big locks around some bits (the compiler, notably) which need granulating, but in general a concerted effort to tackle library threadsafety would be a good thing. - -dan - -- http://www.cliki.net/ - Link farm for free CL-on-Unix resources -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+58z0HDK5ZnWQiRMRAkXSAJ4n1lyLxVz8iyLm81+pCXnGx9piYgCfSfrs 8DuPeLLawdPrF5d7F3xyvi4= =FN4u -----END PGP SIGNATURE-----
