Squeak and native threads

J J 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 
that).

>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
	instanceVariableNames: 'balance'
	classVariableNames: ''
	poolDictionaries: ''
	category: 'Banking'

BankAccount>>withdraw: aNumber

  balance := balance - aNumber.

  balance < 0 ifTrue: [ OverDrawn raise ].

  ^ balance

BankAccount>>deposit: aNumber
  balance := balance + aNumber.
  ^ balance.

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 
would expect).

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.

Thanks,
J

>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: 
>http://www.nabble.com/Squeak-and-native-threads-tf2930209.html#a8241472
>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 
http://shopping.msn.com/content/shp/?ctid=198,ptnrid=176,ptnrdata=200639




More information about the Squeak-dev mailing list