[plt-dev] thread-specifics [PATCH]

On Tue, 3 Mar 2009, Matthew Flatt wrote:

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

I can see a few problems here:
1) The key in the value problem - the threads may well refer to themselves
    this complicates the access patterns in the hashtable
2) Access permissions
    There is concurrency involved in the updates.
    The specific access protocol provides memory consistent:
     The owner thread can write atomically
     Everybody can read atomically and always sees the last value placed
      by the owner in trace causality sense.
     The specific is asynchronous and very very cheap.

In addition, the fact that specific is a slot that makes a lightweight 
tool (without having to go to all this) for easily implementing common 
synchronization patterns:  barriers, async completion tokens, thread tags, 
etc

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

I am arguing that the extant solution (the weak hash) does not provide
the functionality specifics provide without significant implementation 
complexities.

Also, with regards to composition: by limiting the specific to a single 
cell, the compositional properties can be managed at the language level 
(scheme/base) where you are not limited by what you can reasonably do in 
the core.

-- vyzo