Neil Jerram <neil@ossau.uklinux.net> writes:

> Many thanks for your input on this.  I'll go ahead with a mutex or
> rwlock.  First thing is to see if it fixes the problem; if it does,
> I'll try to measure the performance impact.

Attached are 3 patches relating to thread-safe define.

#1 is Linas's test-define-race test, modified by me.  This test
reliably fails (without the following fix) if run for 200 seconds, but
I don't think we can have a test in Guile's "make check" that takes
200s.  Therefore I've coded it so that

- it runs for a duration specified by environment variable
  GUILE_TEST_DEFINE_RACE_DURATION

- it defaults to just 10s if that variable isn't defined.

So people who want to run this test meaningfully on their platforms
can do "GUILE_TEST_DEFINE_RACE_DURATION=200 make check".

#2 makes the symbols hash thread-safe, and it appears that this
completely fixes the define-race problem.  I don't understand why we
apparently don't need patch #3 as well - but that's what my results
indicate.

#3 allows a non-weak hash table to be automatically thread-safe, by
associating a fat mutex with it.

#3 is what I tried first, applying it to the module-obarray of the
(guile) and (guile-user) modules.  But test-define-race still gave
errors.  Then I added #2, and that fixed the errors.  Then I checked
#2 without #3, and that fixes all the test-define-race errors too.  So
apparently #3 is not needed.

It looks like we should commit #1 and #2 (although maybe with rwlock
instead of mutex), so please send any comments you have on those.  I'd
also appreciate thoughts on #3 as a possible hash table enhancement
(for master), and on why we don't apparently need to make the module
obarray hash tables thread-safe in this way.

Regards,
        Neil