[Top][All Lists]

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

Re: Race condition in threading code?

From: Han-Wen Nienhuys
Subject: Re: Race condition in threading code?
Date: Sun, 31 Aug 2008 20:59:19 -0300
User-agent: Thunderbird (X11/20080723)

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

/* 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 -

reply via email to

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