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: [email protected] [[email protected]] On Behalf Of Levente Uzonyi [[email protected]] 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 <[email protected]> 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. > > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
