On Wed, Oct 13, 2010 at 11:53 AM, Igor Stasenko <siguctua at gmail.com> wrote:

> 2010/10/13 Levente Uzonyi <leves at elte.hu>:
> > 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:
>
> i don't like the code, which assuming that scheduling works in some
> specific way,
> or some code can't be interrupted in the middle.
>
> See Semaphore>>critical: for excersise.
>
> | caught |
>        caught := false.
>        ^[
>                caught := true.
>                self wait.
>                mutuallyExcludedBlock value
>        ] ensure: [ caught ifTrue: [self signal] ]
>
> this code assuming that between
>                caught := true.
> and
>                self wait.
>
> no interrupt possible.
> But if it is, then the above implementation is incorrect.
>
>
> >
> > 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.
> >
>
> For same reason, there is no any guarantees from VM side that three
> assignments in a row will be
> atomic: storing pointer could trigger a root check, and if roots table
> is full, it could trigger GC,
> and after GC, there is a finalization semaphore, which could switch an
> active process immediately.
>
> VM is evolving and subject to change. Having a clear rule which
> guarantees a specific behavior is far more
> beneficial comparing to intimate knowledge about how VM works (now).
>

+1.  I think there's general agreement on this.  All this uninterruptibiity
goes out of the window (as does Processor activeProcess) as soon as anyone
does a truly concurrent implementation.

best
Eliot

>
>
> >
> > 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.
> >>
> >
> >
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20101013/c811c9cc/attachment.htm