[plt-dev] thread-specifics [PATCH]

From: Dimitris Vyzovitis (vyzo at media.mit.edu)
Date: Tue Mar 3 15:05:04 EST 2009

On Tue, 3 Mar 2009, Matthew Flatt wrote:

> At Tue, 3 Mar 2009 14:39:39 -0500 (EST), Dimitris Vyzovitis wrote:
>> On Tue, 3 Mar 2009, Matthew Flatt wrote:
>>
>>> Is there a reason this needs to be built in, instead of implemented as
>>> a weak hash table?
>>
>> There is no rendezvous needed to access the specific, because it is
>> attached to the thread (a public readonly cell), simplifying things with
>> barriers, tagging, etc.
>
> There's also no rendezvous for an `eq?'-based weak hash table (which is
> the variant suitable for mapping threads to values).
>
> More precisely, the rendezvous is implemented in each case by atomicity
> of the core.

Well, I take it you mean having a global weak-hash table here? That is 
rendezvous in itself, because it has to be accessed and implement a 
synchronization protocol to it.

The specific is not weak - it is a thread-attached property that can 
be written only by the thread itself (thus communicating internal state 
information) and read by every other thread that has a reference to it.

As a primitive, the specific is a low level synchronization primitive, 
with the function of volatile synchronous broadcasts [and it has 
associated event semantics by being attached to a thread].


>> The thread can set a weak table in its specific if for key/value access.
>
> But it's only composable to the degree that everyone who can seet a
> thread uses the weak hash table...

Well, the specific a hash-table by default; But I don't think that 
weakness of keys should be enforced at such low level, and in general
I prefer to keep most general nature of the primitive.

-- vyzo


Posted on the dev mailing list.