guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Race condition in threading code?


From: Ludovic Courtès
Subject: Re: Race condition in threading code?
Date: Mon, 01 Sep 2008 10:11:09 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Hi,

Han-Wen Nienhuys <address@hidden> writes:

> I don't understand: memoization is only supposed to happen once for
> each piece of code, right?  So, the cost of it is not that interesting?

Yes, it's done only once, but if a piece of code hasn't yet been
memoized and is called simultaneously by several threads, then we have a
problem.

> I remember seeing a very scary looking explanation in eval.c about the
> evaluator being unlocked but still thread-safe since the result of memoizing
> was supposed to be confluent (ie. duplicate runs would yield independent
> results.)
>
> /* The Lookup Car Race
>     - by Eva Luator

That comment only relates to `scm_lookupcar ()'...

> Is that the only one?
>
>   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 
> ****!!! ?

You're right, troubles all around!

> At the very least, we should have an atomic SCM_SETCELL() which overwrites 
> car and
> cdr atomically.

I'm not sure whether than can be done, since that's two machine words.
At any rate, that wouldn't be sufficient, e.g., to fix `scm_m_letstar ()'.

Thanks,
Ludo'.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]