Re: Race condition in threading code?

[Han-Wen Nienhuys]

Ludovic Courtès escreveu:
> Hello,
> 
> Andy Wingo <address@hidden> writes:
> 
>> ERROR: srfi-18.test: thread-start!:
>>   thread activates only after start
>>    - arguments: ((syntax-error "memoization"
>>                   "In file ~S, line ~S: ~A ~S in expression ~S."
>>                   ("/home/lilydev/vc/guile/srfi/srfi-18.scm" 135
>>                    "Bad binding" ct
>>                     (let (ct (current-thread))
>>                     address@hidden (or (hashq-ref thread-exception-handlers 
>> ct)
>>                           (hashq-set! thread-exception-handlers ct
>>                     (list initial-handler))))) #f))
> 
> I'm seeing this as well, but it's a address@hidden' here (single-binding 
> `let's
> are memoized as address@hidden'):
> 
>   ((syntax-error "memoization"
>                  "In file ~S, line ~S: ~A ~S in expression ~S."
>                  ("/home/ludo/src/guile/srfi/srfi-18.scm" 138
>                   "Bad binding"
>                   ct
>                   (address@hidden (ct (#<variable b7d28110 value: 
> #<primitive-procedure current-thread>>))
>                     (address@hidden (#<variable b7d2ad88 value: 
> #<primitive-procedure hashq-ref>>
>                                       #<variable 839df08 value: 
> #<weak-key-hash-table 1/31>> address@hidden)
>                           (#<variable b7d2adc0 value: #<primitive-procedure 
> hashq-set!>> #<variable 839df08 value: #<weak-key-hash-table 1/31>> 
> address@hidden (#<variable b7d2c498 value: #<primitive-procedure list>> 
> #<variable 839d130 value: #<procedure initial-handler (obj)>>))
>                           )))
>                  #f))
> 
> It can be reproduced, but very infrequently, with this program:
> 
>   (use-modules (ice-9 threads))
> 
>   (define (foo x y)
>     (let ((z (+ x y)))
>       (let ((a (+ z 1)))
>         (let ((b (- a 2)))
>           (let ((c (* b 3)))
>             c)))))
> 
>   (define (entry)
>     (foo 1 2))
> 
>   (for-each (lambda (i) (make-thread entry))
>             (iota 123))
> 
> My explanation is that the `let*' memoizer, aka. `scm_m_letstar ()', is
> not thread-safe; it's clearly not atomic, and it's of course not
> protected by a mutex or so.
> 
> I can't think of any simple fix.  `scm_m_letstar ()' could be made
> atomic by having it duplicate the input list instead of modifying it
> directly; it could then atomically update the input.  However,
> allocating cells during memoization wouldn't be a good idea
> performance-wise.

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?

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

This was added by Marius Vollmer, but at the time, GUILE did not support
real posix threads, so any problem may not have manifested itself before.

-- 
 Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen