Re: Race condition in threading code?

[Andy Wingo]

Hello!

On Tue 02 Sep 2008 21:56, Han-Wen Nienhuys <address@hidden> writes:

>>   SCM
>>   scm_m_let (SCM expr, SCM env)
>>   ...
>>       /* plain let */
>>       SCM rvariables;
>>       SCM inits;
>>       transform_bindings (bindings, expr, &rvariables, &inits);
>> 
>>       {
>>         const SCM new_body = m_body (SCM_IM_LET, SCM_CDR (cdr_expr));
>>         const SCM new_tail = scm_cons2 (rvariables, inits, new_body);
>>         SCM_SETCAR (expr, SCM_IM_LET); 
>>         // ****!!!
>>         SCM_SETCDR (expr, new_tail);
>> 
>> What happens if another thread tries to evaluate expr at the place marked 
>> ****!!! ?
>> 
>> At the very least, we should have an atomic SCM_SETCELL() which overwrites 
>> car and
>> cdr atomically.
>
> Anyone?  Does anyone still understand how the evaluator works?

It sounds to me like you're right; and it sounds very similar to the
lookup car race. Anything that mutates the code structure in place
(memoized or not) needs to be atomic; we can rely on all threads
reaching the same conclusion, as in the lookup car race, but the actual
mutation should happen atomically.

>  (if not, let's move 
> to the VM earlier than later.)

I think we have much more experience with the bugs of the interpreter
than the bugs of the vm ;-)

Seriously, it is good to have both -- for bug checking, sanity testing,
and avoiding circularity. Otherwise we have to start distributing .go
files. Guile's interpreter is fantastic, and there's no reason to throw
it out -- although we may want to make it simpler, and push much of the
optimization efforts into the vm.

Andy
-- 
http://wingolog.org/