From: Gábor M. <me...@re...> - 2009-06-18 15:50:37
|
Tobias asked about the % in %symbol-value-in-thread the other day. The reasons I could see were: 1) you may see a stale value 2) boundness detection is buggy 3) the object may be gc'ed before make-lisp-obj is called with the address I think all three observations are still valid with the code committed: + ;; Prevent the thread from dying completely while we look for the TLS + ;; area... + (with-all-threads-lock + (if (thread-alive-p thread) + (let* ((offset (* sb!vm:n-word-bytes + (sb!vm::symbol-tls-index symbol))) + (tl-val (sap-ref-word (%thread-sap thread) offset))) + (if (eql tl-val sb!vm::no-tls-value-marker-widetag) + (values nil :unbound) + (values (make-lisp-obj tl-val) :bound))) + (values nil :dead)))) In particular: - SYMBOL-TLS-INDEX may be stale - TL-VAL may be stale - TL-VAL can be UNBOUND-MARKER-WIDETAG - TL-VAL may be gc'd between SAP-REF-WORD and MAKE-LISP-OBJ It can be argued that for the known use-cases (slime debugger) the first two are relatively harmless. The unboundness oversight can be fixed. The gc bit, though, is not so easy. In fact, at the time I could see no way to get it right and came to agree with Dan's comment: ;;; internal use only. If you think you need to use these, either you ;;; are an SBCL developer, are doing something that you should discuss ;;; with an SBCL developer first, or are doing something that you ;;; should probably discuss with a professional psychiatrist first cheer, Gabor |
From: Nikodemus S. <nik...@ra...> - 2009-06-18 16:00:32
|
2009/6/18 Gábor Melis <me...@re...>: > - SYMBOL-TLS-INDEX may be stale This one I don't understand. How can it be stale? > - TL-VAL may be stale True, but this seems harmless to me -- or maybe I misunderstand what you mean. > - TL-VAL can be UNBOUND-MARKER-WIDETAG Oops, right. Easy to fix, though. > - TL-VAL may be gc'd between SAP-REF-WORD and MAKE-LISP-OBJ Oops, right. It seems to me that checking either *GC-EPOCH* or verifying that the TL-VAL has not changed between the time we constructed the lisp-object and originally fetched it should deal with this -- sure, we may spin, but this is primarily a debugging tool after all, so I don't see an problem with that. Cheers, -- Nikodemus |
From: Gábor M. <me...@re...> - 2009-06-18 16:20:11
|
On Jueves 18 Junio 2009, Nikodemus Siivola wrote: > 2009/6/18 Gábor Melis <me...@re...>: > > - SYMBOL-TLS-INDEX may be stale > > This one I don't understand. How can it be stale? You may see 0 if the tls index has been allocated recently by another thread (on another cpu). > > - TL-VAL may be stale > > True, but this seems harmless to me -- or maybe I misunderstand what > you mean. I mean the same thing as above: the TL-VAL the calling thread sees may not be what is in the target thread. It probably is indeed harmless. > Oops, right. Easy to fix, though. > > > - TL-VAL may be gc'd between SAP-REF-WORD and MAKE-LISP-OBJ > > Oops, right. It seems to me that checking either *GC-EPOCH* or > verifying that the TL-VAL has not changed between the time we > constructed the lisp-object and originally fetched it should deal > with this -- sure, we may spin, but this is primarily a debugging > tool after all, so I don't see an problem with that. Wouldn't having a lisp obj that points to a random address in the heap be a bad thing? If it is then I think this cannot be done without without-gcing. > Cheers, > > -- Nikodemus |
From: Nikodemus S. <nik...@ra...> - 2009-06-18 16:29:59
|
2009/6/18 Gábor Melis <me...@re...>: >> This one I don't understand. How can it be stale? > > You may see 0 if the tls index has been allocated recently by another > thread (on another cpu). Since the user has no way to tell that, I consider this acceptable. At least I think the user cannot tell this apart from the unavoidable race between the thread binding the variable and another trying to read it using S-V-I-T. If I'm missing something there, then SYMBOL-TLS-INDEX needs a barrier. >> > - TL-VAL may be stale >> >> True, but this seems harmless to me -- or maybe I misunderstand what >> you mean. > > I mean the same thing as above: the TL-VAL the calling thread sees may > not be what is in the target thread. It probably is indeed harmless. Right. >> > - TL-VAL may be gc'd between SAP-REF-WORD and MAKE-LISP-OBJ >> >> Oops, right. It seems to me that checking either *GC-EPOCH* or >> verifying that the TL-VAL has not changed between the time we >> constructed the lisp-object and originally fetched it should deal >> with this -- sure, we may spin, but this is primarily a debugging >> tool after all, so I don't see an problem with that. > > Wouldn't having a lisp obj that points to a random address in the heap > be a bad thing? If it is then I think this cannot be done without > without-gcing. As long as threads are only on GENCGC, and the value is in register or on stack, not a problem. Cheers, -- Nikodemus |
From: Nikodemus S. <nik...@ra...> - 2009-06-18 16:33:51
|
2009/6/18 Nikodemus Siivola <nik...@ra...>: >> Wouldn't having a lisp obj that points to a random address in the heap >> be a bad thing? If it is then I think this cannot be done without >> without-gcing. > > As long as threads are only on GENCGC, and the value is in register or > on stack, not a problem. I neglected to mention that the reason I'm avoiding WITHOUT-GCING is deadlocking on WITH-ALL-THREADS-LOCK -- I'd rather not make it a WITHOUT-GCING-only lock. Cheers, -- Nikodemus |