Squeak and native threads
azreal1977 at hotmail.com
Tue Jan 9 17:33:34 UTC 2007
Well, I think the transactional approach could work nice as well (of course
squeak already has semaphore style fine grain locking if you really want
>From a synchronization point of view, there are only two cases to worry
about (I think):
1) Object getting into an invalid state due to an update
2) Updates getting lost
In case 1, only the object can know if it is in an invalid state or not, so
this has to be explicit:
Object subclass: #BankAccount
balance := balance - aNumber.
balance < 0 ifTrue: [ OverDrawn raise ].
balance := balance + aNumber.
BankAccount>>transfer: aNumber to: anAccount
anAccount deposit: aNumber.
self withdraw: aNumber.
] asAtomicBlock value.
If another thread drops the account below 0 while #transfer:to: is running,
the #withdraw: will throw an exception, undo the deposit (or simply throw
away the uncommited changes) and propagate the exception up (as the caller
Now the harder one: missed updates. My thought on this was, maybe everthing
on the right of := could be considered atomic. This might let most of the
current code run ok in the presence of threads.
Of course the AtomicBlock class will have to use primitives to do the
book-keeping needed, but I think smalltalk might be in a fairly unique
position to take advantage of for optimizations. For example, if the VM
sees there is only 1 thread, then skip the book-keeping. Transactional
memory is generally slower with 1-4 threads, but I think with the example
optimization it could be at least as fast as fine-grained locking when
running a single thread.
>From: Zulq <zulqarnain.t.alam at jpmorgan.com>
>Reply-To: The general-purpose Squeak developers
>list<squeak-dev at lists.squeakfoundation.org>
>To: squeak-dev at lists.squeakfoundation.org
>Subject: Re: Squeak and native threads
>Date: Tue, 9 Jan 2007 08:43:15 -0800 (PST)
>J J-6 wrote:
> > That is, the best would be if some change could be made
> > and squeak was suddenly capable of running in multiple threads with the
> > current code base.
>I agree and that is why I found the active object + asynchronous messages
>model interesting. From what I can tell (so far) there appears to be even
>less impact. In a transactional system you would need some sort of
>transactional construct like BlockClosure>>atomicValue:anObject which seems
>unpleasant to me. Furthremore, I imagine the cost of having implicit
>transactions for every instance variable would be significantly high.
>View this message in context:
>Sent from the Squeak - Dev mailing list archive at Nabble.com.
Find sales, coupons, and free shipping, all in one place! MSN Shopping
Sales & Deals
More information about the Squeak-dev