Re: [Sbcl-devel] Bugs in dynamic variable binding, setting, etc. (Linux/x86 builds with thread support)

[<me...@ho...>]

On Wednesday 10 August 2005 12:55, Hannu Koivisto wrote:
> Greetings,
>
> I was reading dynamic variable related VOPs for builds with thread
> support in src/compiler/x86/cell.lisp of SBCL from CVS as of
> 2005-07-29 (the file hasn't changed since so I assume the problems
> are still relevant) and saw things that I thought couldn't work.
>
> First I noticed that the use of *free-tls-index* variable (TLS
> index allocation) in the BIND VOP seemed thread-unsafe:
>
>   ;; allocate a new tls-index
>   (load-symbol-value tls-index *free-tls-index*)
>   (inst add tls-index 4)            ;XXX surely we can do this more
>   (store-symbol-value tls-index *free-tls-index*) ;succintly
>
> More than one symbol may end up with the same TLS index.  Then I
> noticed that the entire "need to allocate? - allocate - store
> allocated value - use allocated value" logic didn't seem to be
> thread-safe even if allocation itself was.  Let's consider a case
> with only two threads.  If they end up allocating a tls-index for
> the same symbol at the same time, only one of them stays in the
> symbol's tls-index slot and is thus the only one used for all
> future references, but the thread whose TLS index was overwritten
> still uses this walking dead index to store the given value.
> I.e. I think it would be possible for (let ((*foo* 1)) (boundp
> '*foo*)) to evaluate to NIL if the global value was not bound.

Another one for review. Look out for bugs/suboptimalities in the=20
assembly and the vop declarations.

The attach patch introduces *TLS-INDEX-LOCK* that's held during the=20
"transaction" of incrementing *FREE-TLS-INDEX* and setting the=20
tls-index of the symbol. The whole thing is wrapped in a pseudo-atomic=20
to protect against interrupts and gc.

Basically the same thing is done in three places: the x86 vop, the=20
x86-64 vop and dynbind() that's used by the runtime. Seems to work and=20
my vop-fu has risen slightly above zero by now.

Tested on x86 and x86-64. No regressions, but since I couldn't trigger=20
the bugs it may not mean victory.

Cheers, G=E1bor