[Pharo-project] [squeak-dev] Re: How about atomic value-swap bytecode?

Schwab,Wilhelm K bschwab at anest.ufl.edu
Wed Oct 13 13:14:48 EDT 2010


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 at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves at 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 at 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.
>
>




More information about the Pharo-dev mailing list