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:
 ClassicTimerSupport class>>scheduleTimerEphemeron:
 ClassicTimerSupport class>>scheduleTimer:
 optimized  in ClassicTimerSupport class>>timingLoop
 ClassicTimerSupport class>>timingLoop
 optimized  in ClassicTimerSupport class>>configureTimerSystem
 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 ...
Since this is not the case is the comment in the following method still valid???
"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
| 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].
[Processor activeProcess terminate].
Cham Püschel & Nicole de Graaf
vwnc mailing list
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.
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.
vwnc mailing list
|Free forum by Nabble||Edit this page|