On Mar 4, 2006, at 12:07 PM, Thomas Chust wrote:
On Sat, 4 Mar 2006, KonLovett wrote:
On Mar 2, 2006, at 4:37 AM, Thomas Chust wrote:
Hello,
just a small question: Are CHICKEN's hash tables threadsafe by
design or do I have to surround all hash table accesses in
multithreaded applications by a mutex-lock! / mutex-unlock! pair?
FWIW my reading of the source is 1) No & 2) Yes. You could
surround access w/ disable/enable interrupts, since that would
inhibit a context switch by the schedular during the access. But I
think creating a "thread-safe" wrapper around your shared data-
structure, as you suggest, is the best.
[...]
Hello,
so you think I can mess up the internal data structure of a hash
table if I access it concurrently from two threads? That's nasty.
I'll have to put a bazillion of those
(dynamic-wind
(lambda () (mutex-lock! some-hash-mtx))
(lambda () (do-something-to (mutex-specifix some-hash-mtx)))
(lambda () (mutex-unlock! some-hash-mtx)))
blocks into my code. But thank you for telling me, because after
some tests I thought the hash tables *were* thread safe.
Well, testing tells. I just don't see, after cursory inspection (the
FWIW above), anything to stop a context switch during processing of a
hash-table mutator (see 'extras.scm'). But, I would ask Felix for an
authoritative answer.
In any case, macros can do wonders for those bazillion nasty code
sequences ;)
cu,
Thomas
_______________________________________________
Chicken-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/chicken-users
