But my example (theoretically) worked as written.  Everything to the right 
of the := is protected so saying "balance := balance - aNumber" doesn't risk 
losing the update.  And even without this, so long as calls to #withdraw: 
and #deposit: are always done in #transfer:to: they are protected by *that 
method's* atomic operation.

That is one of the great things about STM (software transactional memory); 
you can compose atomic operations transparently.  That is, you can just use 
methods and not be so concerned about if they do atomic operations or not.  
That is quite a departure from fine-grained locking code.


>From: Zulq Alam <me at zulq.net>
>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, 09 Jan 2007 20:51:09 +0000
>
>Sorry, I meant in your BankAccount example. I was thinking about some kind 
>of switch to make specific Objects begin implicit transactions for each 
>message received. This switch could optionally be used in conjunction with 
>explicit transactions. The goal being to reduce the code changes required.
>
>| bankAccount |
>bankAccount := BankAccount new.
>
>" implicit transactions for all methods "
>bankAccount shareAll
>
>" implicit transactions for only #transfer:to "
>bankAccount share: #transfer:to
>
>" no implicit transactions "
>bankAccount shareNone
>
>I greatly prefer the asynch/active model as none of this seems necessary 
>(from what I have read so far). As far as I can tell, the developer need 
>not do *anything* different to benefit and be protected from
>concurrency.
>
>J J wrote:
>>But they don't.  Only variables updates (NOTE: most reads don't) do.
>
>

_________________________________________________________________
Type your favorite song.  Get a customized station.  Try MSN Radio powered 
by Pandora. http://radio.msn.com/?icid=T002MSN03A07001