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
_________________________________________________
For list-related administrative tasks:
http://list.cs.brown.edu/mailman/listinfo/plt-dev
