[Ecls-list] thread-specific data

Tobias C. Rittweiler tcr at freebits.de
Tue Mar 16 10:16:01 UTC 2010


Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> writes:

> On Tue, Mar 16, 2010 at 9:22 AM, Tobias C. Rittweiler <tcr at freebits.de>wrote:
>
>> Yes. Two points here: a) many implementations provide a special variable
>> and a keyword parameter on MAKE-THREAD for default bindings in new
>> threads
>
>
> That happens also with MP:MAKE-PROCESS
> http://ecls.sourceforge.net/new-manual/re21.html
>
>
>> , b) it will create thread-local bindings, but not thread-local
>> data. I.e. the data will be part of the general Lisp heap, and can be
>> freely shared between threads.
>> It has not been implemented yet, but I made the suggestion on SBCL's bug
>> tracker to introduce a THREAD-LOCAL-VALUE special form a la
>> LOAD-TIME-VALUE.
>>
>
> What would be the rationale and specification for such a THREAD-LOCAL-VALUE?
> Aren't special variable bindings enough?

The rationale is to have something like local static in C but being
thread-safe, e.g.

  (let ((x (thread-local-value 0)))
    #'(lambda ()
        (incf x)
        ...))

depending on the actual semantics of THREAD-LOCAL-VALUE, the following
may in fact be possible too:

  #'(lambda ()
      (let ((x (thread-local-value 0)))
        (incf x)
        ...))

Perhaps a declaration is indeed better because it does seem to be tied
to bindings (question is whether inherently and whether there's a
plausible use case for not tieing it to bindings) -- and with DX,
there's already a declaration customizing allocation, so both approaches
seem to be compatible to the standard, mindwise.

  -T.





More information about the ecl-devel mailing list