Is the comment BlockClosure>>valueAsUnwindBlockFrom: still valid?

Let people know what version of VW you are using. It is likely a bug that only exists in recent VW releases. A class named "ClassicTimerSupport" implies that there is a new and (presumed) better TimerSupport that would likely be used by default. Did you configure ClassicTimerSupport for a reason?

Look for a deadlock situation. You found two processes that are waiting, but what is the process doing that is holding the semaphore? That process is likely waiting for some other semaphore. One of the waiting processes may have that other semaphore being held earlier in the stack. In that case two processes each hold one of two semphores that the other process is waiting (forever) for. Tools that (without getting stuck) allow you to dump all process stacks to a file are useful for debugging situations like this. Remedies are to narrow the use of at least one of the semaphores or to use a consistent acquisition order.

Another scenario to look for is recursive use of the semaphore. A normal Semaphore waits for the release of a lock that it holds (and would never release) before it can execute the critical block. It is easy to see these in a stack dump, you just look for the same semaphore used earlier in the stack. A RecursionLock semaphore allows the same process back through the critical region. Remedies for that include reducing how much code gets executed in a critical block or using a RecursionLock instead.

VW is known to get window freezes when a click is treated as as a drag operation that then gets stuck. It happens randomly when someone mouse clicks with a little movement. It is very irritating and last I inquired it still happens in recent VW releases too. If that is happening then you'll notice drag related code in the stack when you interrupt execution. I presume that isn't the case here, but I thought I'd mention it because it stops window updates.

Paul Baumann

Hi,

In our currently deployed application we have the situation that all our windows aren't updated anymore (all screens end up gray).
We have multiple dumpfiles from different machines and customers were it seems that a Semaphore (forMutalExclusion) has not been signaled.
The Semaphore in question is the TimerLock in ClassicTimerSupport. This semaphore is used in 4 methods in ClassicalTimerSupport all sending critical: to it.
In the dumpfile we only see the following references to ClassicalTimerSupport:

[1]     Semaphore>>waitIfCurtailedSignal
[2]     Semaphore>>critical:
[3]     ClassicTimerSupport class>>scheduleTimerEphemeron:
[4]     ClassicTimerSupport class>>scheduleTimer:
[5]     ClassicTimerSupport>>enableTimer:atMicroseconds:every:
[6]     ClassicTimerSupport>>enableTimer:after:every:
[7]     Timer>>privateStartAfter:

[1]     Semaphore>>waitIfCurtailedSignal
[2]     Semaphore>>critical:
[3]     optimized [] in ClassicTimerSupport class>>timingLoop
[4]     BlockClosure>>repeat
[5]     ClassicTimerSupport class>>timingLoop
[6]     optimized [] in ClassicTimerSupport class>>configureTimerSystem
[7]     BlockClosure>>on:do:
[8]     optimized [] in Process class>>forBlock:priority:


Both processes are not running the mutuallyExcludedBlock but are waiting in waitIfCurtailedSignal.
Nowhere in all the dumpfiles we have a process that is actually executing the mutuallyExcludedBlock.
We should see then the following stack:

[]    optimized [] in ...
[]    BlockClosure>>ensure:
[]    Semaphore>>critical:

Since this is not the case is the comment in the following method still valid???

BlockClosure>>valueAsUnwindBlockFrom: aContextOrNil
    "Unwind blocks are evaluated using this wrapper.
    This method is marked as special.  When the
    system searches for unwind blocks, it skips over
    all contexts between this context and the context
    passed in as an argument.  If the argument is
    nil, it skips over the sender of this context.

    The purpose of this is that errors inside an
    unwind block should not evaluate that unwind
    block, and they should not circumvent the
    running of other unwind blocks lower on the
    stack."

    <exception: #unwindInAction>

    | shouldTerminate |
        "The first temporary variable in this method is treated specially by Process>>terminate,
        which may set it to true. If that happens, terminate the process at the end of the unwind action.
        Normally we should be able to take for granted that shouldTerminate has nil as its initial
        value, but since this variable is modified by another process, it's possible that the other
        process could set the value to true when this process is waiting at the initial PC of the method.
        In that case, when this process resumes, it needs to make sure that it doesn't overwrite
        the true with a false.

        On a purely theoretical level, there's still room for a race condition between testing for nil
        and assigning false to the variable, but in practise our execution technology doesn't allow
        for a process switch between the test and the assignment, so the only way it could be a
        problem in practise is if the method were being debugged or run by a VI level interpreter
        at the time that some other process wanted to terminate it. At this time, the risk of that kind
        of situation seems so much smaller thatn the risk of a process switch at the initial PC, that
        we're willing to fix only the initial PC case."
    shouldTerminate == nil ifTrue: [shouldTerminate := false].
    self value.
    shouldTerminate
        ifTrue:
            [Processor activeProcess terminate].

Regards,

Cham Püschel & Nicole de Graaf