[Top][All Lists]
[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: |
Sun, 31 Aug 2008 22:08:37 +0200 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) |
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.
Thanks,
Ludo'.
- Re: Race condition in threading code?, (continued)
- Re: Race condition in threading code?, Ludovic Courtès, 2008/08/27
- Re: Race condition in threading code?, Julian Graham, 2008/08/27
- Re: Race condition in threading code?, Julian Graham, 2008/08/30
- Re: Race condition in threading code?, Han-Wen Nienhuys, 2008/08/30
- Re: Race condition in threading code?, Julian Graham, 2008/08/30
- Re: Race condition in threading code?, Han-Wen Nienhuys, 2008/08/31
- Re: Race condition in threading code?, Ludovic Courtès, 2008/08/31
- Re: Race condition in threading code?, Ludovic Courtès, 2008/08/31
- Re: Race condition in threading code?, Julian Graham, 2008/08/31
- Re: Race condition in threading code?, Ludovic Courtès, 2008/08/31
- Re: Race condition in threading code?,
Ludovic Courtès <=
- Re: Race condition in threading code?, Han-Wen Nienhuys, 2008/08/31
- Re: Race condition in threading code?, Han-Wen Nienhuys, 2008/08/31