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
