Efficient thread-local shared variables

Reinout Heeck reinz at desk.org
Tue Oct 24 14:17:30 UTC 2006


On Oct 24, 2006, at 12:18 PM, ncellier at ifrance.com wrote:

> So you have to share the first literal between read and write  
> access methods ?
> like pseudo byte code:
> key
>   ^(literalAt: 1) value
>
> key: aValue
>   ^(literalAt: 1) value: aValue

Your code confuses me, but you seem to be talking about implementing  
Association behavior. In my scheme CompiledMethods come closest to  
this role.

So getting to the 'association' could be implemented on the anonymous  
class as

associationAt: aSymbol
   ^self compiledMethodAt: aSymbol

then CompiledMethod could implement

key
   ^self selector

value
   ^self localAt: 1


Changing the value is something I haven't needed/tried yet because in  
VW matters are complicated by the JIT cache that would (might?) need  
to be flushed. This requires me getting to the class that holds this  
CompiledMethod. Conceptually:

value: anObject
   self localAt: 1 put: anObject.
   self classThatImplementsMe flushVMMethodCashesFor: self selector.


Overall I'm not too keen on modeling full dictionary behavior because  
my 'dictionary' is already different in that it is reified as two  
objects (the anonymous class and its singleton instance), the class  
can be regarded as a mirror-like accessor to the dictionary for doing  
'meta' queries like getting to an 'association' and for altering the  
dictionary contents. The singleton instance is used for lookup only  
(any support methods implemented on it would clash with keys you  
might want to use, currently only #doesNotUnderstand: is implemented  
on my anon class).




One of my pet peeves about St is that #doesNotUnderstand: should be  
implemented on he class side so it doesn't pollute the object's  
selector namespace...

R
-





More information about the Squeak-dev mailing list