FWIW, Dolphin has (or at least had in earlier versions - I can check later if it matters) an analog to #valueUnpreemptively. Something like that is likely to be more portable than new syntax or a new bytecode. Any VW experts care to comment on what might be available there? Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Wednesday, October 13, 2010 1:00 PM To: The general-purpose Squeak developers list Cc: Pharo Development Subject: Re: [Pharo-project] [squeak-dev] Re: How about atomic value-swap bytecode? On Tue, 12 Oct 2010, Igor Stasenko wrote:
On 12 October 2010 16:51, Levente Uzonyi <leves@elte.hu> wrote:
On Tue, 12 Oct 2010, Igor Stasenko wrote:
Hello, i just thought, that it would be cool to have a special bytecode, which guarantees atomicity for swapping values between two variables.
To swap two values, you usually do:
| var1 var2 temp |
temp := var1. var1 := var2. var2 := temp.
But since its non-atomic, a process can be interrupted and such operation is not thread-safe.
In order to make it thread safe, you must add even more boilerplate:
| var1 var2 temp |
semaphore critical: [ temp := var1. var1 := var2. var2 := temp. ]
An alternative solution:
| a b | a := 1. b := 2. [ | tmp | tmp := a. a := b. b := tmp ] valueUnpreemptively
Yeah, another boilerplate under the hood, also highly dependent from scheduling nuances :)
I don't get the "dependency from scheduling nuances part", but here's my idea: Add the compiler changes to support :=: as atomic swap. We don't really need a bytecode for now, since a sequence of assignments is currently atomic. So the compiler could compile :=: as three assignments using a hidden temporary variable. On other systems, :=: can be compiled differently. Levente
valueUnpreemptively "Evaluate the receiver (block), without the possibility of preemption by higher priority processes. Use this facility VERY sparingly!" "Think about using Block>>valueUninterruptably first, and think about using Semaphore>>critical: before that, and think about redesigning your application even before that! After you've done all that thinking, go right ahead and use it..." | activeProcess oldPriority result | activeProcess := Processor activeProcess. oldPriority := activeProcess priority. activeProcess priority: Processor highestPriority. result := self ensure: [activeProcess priority: oldPriority]. "Yield after restoring priority to give the preempted processes a chance to run" Processor yield. ^result
Levente
-- Best regards, Igor Stasenko AKA sig.