2014-07-09 11:19 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:

2014-07-09 2:07 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:

Hi Nicolai,

On Tue, Jul 8, 2014 at 7:19 AM, Nicolai Hess <nicolaihess@web.de> wrote:

I want to create a process doing some work and call #changed on a Morph.
I want to start/suspend/resume or stop this process.
But sometimes, suspending the process locks the UI-Process,
and I don't know why. Did I miss something or do I have to care when to call suspend?

Wrapping the "morph changed" call in

UIManager default defer:[ morph changed].

Does not change anything.

Here is an example to reproduce it.
Create the process,
call resume, call supsend. It works, most of the time,
but sometimes, calling suspend locks the ui.

p:=[[true] whileTrue:[ Transcript crShow: (DateAndTime now asString). 30 milliSeconds asDelay wait]] newProcess.��

p resume.
p suspend.

If you simply suspend this process at random form a user-priority process you'll never be able to damage the Delay machinery you're using, but chances are you'll suspend the process inside the critical section that Transcript uses to make itself thread-safe, and that'll lock up the Transcript.��

Thank you Eliot

yes I guessed it locks up the critical section, but I hoped with would not happen if I the use UIManager defer call.

��

ThreadSafeTranscript>>nextPutAll: value

accessSemaphore

critical: [stream nextPutAll: value].

^value

So instead you need to use a semaphore. ��e.g.

| p s wait |

s := Semaphore new.

p:=[[true] whileTrue:[wait ifTrue: [s wait]. Transcript crShow: (DateAndTime now asString). 30 milliSeconds asDelay wait]] newProcess.

wait := true.

30 milliSeconds asDelay wait.

wait := false.

s signal

etc...

Is this a common pattern I can find in pharos classes. Or I need some help understanding this. The semaphore

wait/signal is used instead of process resume/suspend?

What I want is a process doing repeatly some computation,
calls or triggers an update on a morph, and I want to suspend and resume this process.

I would stop this discussion if someone tells me, "No your are doing it wrong, go this way ..",�� BUT what strikes me:
in this example, that reproduces my problem more closely:

|p m s running|
running:=false.
m:=Morph new color:Color red.
s:= StringMorph new.
m addMorphBack:s.
p:=[[true]whileTrue:[20 milliSeconds asDelay wait. s contents:(DateAndTime now asString). m changed]] newProcess.
m on:#mouseUp send:#value to:[
������ running ifTrue:[p suspend. m color:Color red.]
������ ifFalse:[p resume.m color:Color green.].
������ running := running not].
m extent:(300@50).
m openInWorld

clicking on the morph will stop or resume the process, if it locks up I can still press alt+dot ->

- a Debugger opens but the UI is still not responsive. I can click with the mouse on the debuggers close icon.

- nothing happens, as the UI is still blocked.

- pressing alt+Dot again, the mouse click on the close icon is processed and the first debugger window closes
- maybe other debuggers open.

Repeating this steps, at some time the system is *fully* responsive again!

And miraculously, it works after that without further blockages.

What's happening here?

Nicolai

��

Hi Nicolai,�� I have something for you to try.

With the problem seeming to be stuck in the semaphore critical section, I read around on mutexes and semaphores and found [1] enlightening, which says: "The correct use of a semaphore is for signaling from one task to another. A mutex is meant to be taken and released, always in that order, by each task that uses the shared resource it protects. By contrast, tasks that use semaphores either signal or wait���not both. [...] Any two RTOS tasks that operate at **different priorities** and coordinate via a mutex, create the opportunity for priority inversion [...while...] semaphores [...] do not cause priority inversion when used for signaling." [1]��

To summarize with an example, here's how to use a mutex:
/* Task 1 */
���� mutexWait(mutex_mens_room);
���������� // Safely use shared resource
���� mutexRelease(mutex_mens_room);

/* Task 2 */
���� mutexWait(mutex_mens_room);
���������� // Safely use shared resource
���� mutexRelease(mutex_mens_room);

By contrast, you should always use a semaphore like this:
/* Task 1 - Producer */
������ semPost(sem_power_btn);���� // Send the signal

/* Task 2 - Consumer */
������ semPend(sem_power_btn);�� // Wait for signal

I am out of my depth here, but in light [1] the way the current code seems to mix semaphore/mutex concepts with Semaphore>>forMutalExclusion and Semaphore>>critical:�� gave me some concern.�� Anyway, the delay scheduling code seemed more like a producer/consumer signaling problem than a shared resource mutal exclusion problem, so I rewrote it like the former and fixes the problem without causing any *obvious* problems.�� However I lack experience here and it could definitely use some review.�� Can you take the attached zip file and...

1. File in "Delay class-new delay code part 1.st"
������ Defines #enableNewDelayCode and #enableNewDelayCode:
������ Manually define the referenced class variables

2. File in "Delay class-new delay code part 2.st"
�������� Modifies #handleTimerEvent, guarded by enableNewDelayCode

3. File in "Delay-new delay code part 3.st"
������ Modifies #schedule and #unschedule, guarded by enableNewDelayCode

4. File in "BackgroundWorkDisplayMorph.st"

5. Save checkpoint Image to return to between trials.

6. Open System Browser on BackgroundWorkDisplayMorph>>initialize
������
Trial 1.
BackgroundWorkDisplayMorph new openInWorld.

Trial 2.
Delay enableNewDelayCode: true.
BackgroundWorkDisplayMorph new openInWorld.

If if its deemed worthwhile, I'll open a ticket to track this more formally.�� One thing needed is to considered performance impact, I haven't so far.

cheers -ben

[1] http://www.barrgroup.com/Embedded-Systems/How-To/RTOS-Mutex-Semaphore
[2] http://nerdfortress.com/2011/02/18/you-say-semaphore-i-say-mutex/