[plt-dev] thread-specifics [PATCH]

At Tue, 3 Mar 2009 15:05:04 -0500 (EST), Dimitris Vyzovitis wrote:
> 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?

Yes.

> That is 
> rendezvous in itself, because it has to be accessed and implement a 
> synchronization protocol to it.

I concede that when you share anything, whether a hash table or a
thread references, that there is some sort of rendezvous. But I don't
see why it's more of a problem with a hash table.

> 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.

I mean that the table weakly holds thread references as keys, which is
the usual trick for adding a "field" to an object without changing the
object representation. The specific value should be strongly held, I
imagine.

> 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].

I still believe that this is equally true of `hash-set!' and
`hash-ref'.

> >> 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.

I think we must be talking past each other. To me, it seems like we
already have a suitable general mechanism for extending objects
externally, which is an `eq?'-based hash table with weakly held keys.