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.
