Neil Jerram <n...@ossau.uklinux.net> writes:
> #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.
Maybe it's because the fragments of code passed to scm_c_eval_string
in the test-define-race test are very simple - just
(define x1-100 100)
and
x1-100
- and that scm_c_eval_string consists of reading (=> symbol lookup)
followed by evaluation (=> module obarray lookup), and that each
scm_c_eval_string call is fast enough to be completed well within one
time slice. Then the mutex locking at the start of each symbol lookup
would be enough to make sure that scm_c_eval_string calls on different
threads never overlap with each other.
Does that sound feasible?
(If so, a test like test-define-race, with patch #2 in place, should
still show errors on a multi-core system, or if the code that it
evaluates was made more complex; and use of patch #3 should then fix
those errors.)
Regards,
Neil
