Smalltalk › Squeak › Squeak - Dev

More Delay/Semaphore "fun"

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

30 messages Options

Gary Chambers-4

RE: More Delay/Semaphore "fun"

Possibly. Have you tested this?
For the moment, to allow us to move on, we've switched to Semaphores and avaoided nesting.

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Paolo
> Bonzini
> Sent: 08 October 2007 2:54 PM
> To: [hidden email]
> Subject: Re: More Delay/Semaphore "fun"
>
>
> Gary Chambers wrote:
> > Well, we're finding that you fixes are helping a lot (maybe not
> 100% watertight but much better than without!).
> >
> > For a more difficult challenge:
> >
> > Monitor>>critical:
>
> Not really... It would be more complicated to support *everything* in
> Monitor. But if all you want is a recursion-safe mutex, you can inline
> enter and exit (and the nestingLevel variable is useless now):
>
> | us |
> us := Processor activeProcess.
> ownerProcess == us
> ifTrue: [ ^aBlock value ]
> ifFalse: [
> mutex critical: [
> ["When we enter, the mutex is free so ownerProcess is nil.
> So the unwinding does not mess up anything."
> ownerProcess := us.
> blockValue := aBlock value ]
> ensure: [ ownerProcess := nil ] ] ].
> ^blockValue
>
> The complicated stuff is done in Semaphore>>#critical: and Monitor can
> simply leverage that.
>
> Alternatively, you could have a primitive to notify a waiter on a
> semaphore without adding a signal (a no-op if there is no one waiting).
> This simplifies everything because the excess signals are always
> zero! Then the code would look like this:
>
> reset := false.
> [ ownerProcess == us ] whileFalse: [
> semaphore wait.
> ownerProcess isNil ifTrue: [ownerProcess := us. reset := true]].
> [ blockValue := aBlock value ]
> ensure: [reset ifTrue: [ownerProcess := nil. semaphore notify]].
> ^blockValue
>
> Paolo
>
>

Paolo Bonzini-2

Re: More Delay/Semaphore "fun"

Gary Chambers wrote:
> Possibly. Have you tested this?

Not on Monitor; Monitor>>#exit/#enter are used elsewhere, and as I said
the code is messy enough that you'd better be sure that Monitor-using
processes is never terminated.

> For the moment, to allow us to move on, we've switched to Semaphores and avaoided nesting.

You could instead use Mutex, since I now found out that
Mutex>>#critical: is basically the code I posted.

Paolo

Gary Chambers-4

RE: More Delay/Semaphore "fun"

Aye. Had a chat with Sig on IRC. Mutexes seem to work fine. Had to add critical:ifError: to Mutex though.
Thanks.

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Paolo
> Bonzini
> Sent: 08 October 2007 4:45 PM
> To: The general-purpose Squeak developers list
> Subject: Re: More Delay/Semaphore "fun"
>
>
> Gary Chambers wrote:
> > Possibly. Have you tested this?
>
> Not on Monitor; Monitor>>#exit/#enter are used elsewhere, and as I said
> the code is messy enough that you'd better be sure that Monitor-using
> processes is never terminated.
>
> > For the moment, to allow us to move on, we've switched to
> Semaphores and avaoided nesting.
>
> You could instead use Mutex, since I now found out that
> Mutex>>#critical: is basically the code I posted.
>
> Paolo
>

Steven W Riggins

Re: More Delay/Semaphore "fun"

In reply to this post by Paolo Bonzini-2

On Oct 7, 2007, at 1:46 PM, Paolo Bonzini wrote:

> Plus, as in ST-80 (Blue Book) and Squeak, no interruption can happen
> between "caught := true" and "self wait" because of when interrupts
> are tested for.

I'm naive to all of this stuff, but does the tweak compiler change
these rules, as doesn't it trigger on := assignment? Does this change
this rule at all when running inside of Tweak?

Steve

Bert Freudenberg

Re: More Delay/Semaphore "fun"

On Oct 8, 2007, at 18:25 , Steven W Riggins wrote:

> On Oct 7, 2007, at 1:46 PM, Paolo Bonzini wrote:
>
>> Plus, as in ST-80 (Blue Book) and Squeak, no interruption can happen
>> between "caught := true" and "self wait" because of when interrupts
>> are tested for.
>
> I'm naive to all of this stuff, but does the tweak compiler change
> these rules, as doesn't it trigger on := assignment? Does this
> change this rule at all when running inside of Tweak?

Not for temporary variables, no.

- Bert -

Steven W Riggins

Re: More Delay/Semaphore "fun"

ahha, good stuff. Only fields, alright :)

On Oct 8, 2007, at 9:37 AM, Bert Freudenberg wrote:

> Not for temporary variables, no.

ccrraaiigg

Re: More Delay/Semaphore "fun"

In reply to this post by Andreas.Raab

Hi--

Igor: "Then the only way is to make it to handle all by VM."

Andreas: "Maybe not quite. Check out
http://bugs.squeak.org/view.php?id=6588 to see if this
addresses your problem. It appears to work remarkably
well for me."

Igor: "A bit hacky approach, don't you think?"

Andreas: "Without any doubt. But I don't see a quick solution to
the problem that isn't a bit of a hack. It's not clear
what a VM-driven solution looks like either btw."

I haven't yet thought of a solution that isn't a hack, either. :)
But here's a possible VM-assisted solution:

***

Semaphore>>critical: block
"If I have an excess signal, evaluate block. If I don't, wait for a
signal first."

| marker waited |

"Push a marker into an indexed slot of this context."
marker := #aboutToWaitForCriticalSection.

waited := false.

^[
self wait.
block value
]
ensure: [
"Interpreter>>transferTo: checks to see if it's
transferring to a process whose suspended context has
the above marker in it, at the expected slot. If so, it
sets waited to true, since that process has, in fact,
successfully waited."

waited ifTrue: [self signal]]

***

Although still a hack, it seems simple and sufficiently cheap.
Good for a laugh, anyway. :)

-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

Andreas.Raab

Re: More Delay/Semaphore "fun"

Craig Latta wrote:
> Although still a hack, it seems simple and sufficiently cheap. Good
> for a laugh, anyway. :)

Actually, this is worthwhile to think about. We already have some unwind
protection primitives and it seems quite all right to me to have another
"marker primitive" that could be evaluated upon termination. As a matter
of fact, we might redefine #ifCurtailed: to take an optional argument
which gets to see the suspendingList (or the entire process). Something
along the lines of:

[self wait] ifCurtailed:[:list|
list == self ifTrue:[caught := false].
].

At which point all the VM needs to do is to take the process primitively
#offList which we need anyways.

Cheers,
- Andreas

Paolo Bonzini-2

Re: More Delay/Semaphore "fun"

> Actually, this is worthwhile to think about. We already have some unwind
> protection primitives and it seems quite all right to me to have another
> "marker primitive" that could be evaluated upon termination. As a matter
> of fact, we might redefine #ifCurtailed: to take an optional argument
> which gets to see the suspendingList (or the entire process). Something
> along the lines of:
>
> [self wait] ifCurtailed:[:list|
> list == self ifTrue:[caught := false].
> ].

This is not very different from the idea of a ProcessBeingTerminated
notification.

Paolo

Gary Chambers-4

RE: More Delay/Semaphore "fun"

In reply to this post by Andreas.Raab

Seems like a reasonable way to go. Just grateful that the "interim" fixes are working for us!

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of
> Andreas Raab
> Sent: 10 October 2007 3:27 AM
> To: The general-purpose Squeak developers list
> Subject: Re: More Delay/Semaphore "fun"
>
>
> Craig Latta wrote:
> > Although still a hack, it seems simple and sufficiently
> cheap. Good
> > for a laugh, anyway. :)
>
> Actually, this is worthwhile to think about. We already have some unwind
> protection primitives and it seems quite all right to me to have another
> "marker primitive" that could be evaluated upon termination. As a matter
> of fact, we might redefine #ifCurtailed: to take an optional argument
> which gets to see the suspendingList (or the entire process). Something
> along the lines of:
>
> [self wait] ifCurtailed:[:list|
> list == self ifTrue:[caught := false].
> ].
>
> At which point all the VM needs to do is to take the process primitively
> #offList which we need anyways.
>
> Cheers,
> - Andreas
>