[plt-dev] thread-specifics [PATCH]
At Tue, 3 Mar 2009 15:29:44 -0500 (EST), Dimitris Vyzovitis wrote:
> 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
Ephemerons solve this easily.
> 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.
But `hash-ref' and `hash-set!' handle concurrency.
> 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
Here's an implementation:
#lang scheme/base
(provide specific-ref
specific-set!)
(define specifics (make-weak-hasheq))
(define (specific-ref th [fail (lambda () #f)])
(let ([c (hash-ref specifics th #f)])
(if c
(ephemeron-value c)
(fail))))
(define (specific-set! th v)
(hash-set! specifics th (make-ephemeron th v)))
This doesn't seem complex to me.
It will be a bit slower than your patch. Still, on my machine, 1M
iterations has set and ref takes 0.33 seconds. If I replace the
implementation above with the minimal
(define v #f)
(define (specific-ref th [fail (lambda () #f)])
v)
(define (specific-set! th v2)
(set! v2 v))
then 1M iterations takes 0.14 seconds. So the implementation seems
unlikely to be a performance bottleneck.
> 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.
This is probably a genuine disagreement. I believe that `scheme/base'
is obliged to provide composable abstractions, and not just hooks into
the implementation.