Re: Latest PM123 and WPS freezes

Marty wrote:
However, the information from PSTAT does not look any different to Watchcat at first glance.

PStat shows when a thread is blocked via semaphore or is in a critical section. Watchcat doesn't make this distinction.

Ah, I will try to use this difference.


The question is in the exit list of which threads?
In fact the decoder thread was mostly not in the state unknown. Mostly it were PM threads. But sometimes I had worker threads without any PM initialization in the unknown state too.

To my knowledge the exit list executes as thread 1 exits. There's no concept of an exit list per thread.

OK, from your post I suggested, that there might be something like that.


I don't think that I am able to start PSTAT under this conditions.

If you have non-GUI access to the machine (some kind of telnet or http/cgi access, for example), it will still probably respond and allow you to launch the PSTAT command and capture its output. I do this via Web/2 cgi on my system when things are grim.

Hmm, this is some effort. The only machine that is usually running too is the server. This one nether has a keyboard nor a display connected.


mutex. To run smooth in all cases all threads that use the mutex must raise their priority to the level of the
thread with the highest priority that uses this mutex before they enet the mutex.

DART doesn't work this way. MMOS/2 playlists do. Instead of relying on a thread to "push" audio information out to DART, DART "pulls" the information itself as buffers are emptied.

And in this callback there is a mutex request. Bad design, from my point of view.


Good design for audio applications also won't wait indefinitely on any kind of semaphore. It is better to have a hiccup in the audio, either repeating a full buffer or extending the last sample over the entire next buffer when data is not available, than to halt the thread there.

Well, users of uniaud (with some chipsets) will know that. It will hangup the system once it runs out of recording buffers for some reasons. Maybe it uses a spinlock in the ring 0 code internally.


If they do wind up waiting on a semaphore, and the application starts to shut down while they are waiting, the semaphore can be closed while another thread still waits on it. This leaves the waiting thread in an "unknown" state, hopelessly blocked and never allowed to execute again.

Ah! Is that the cause of unknown thread state?

I would have expected that either DosCloseMutexSem or DosRequestMutexSem would return an error in this case.


The exit list may try to clean up the thread, but will fail and block thread 1 indefinitely also.

However, I also had cases where a kill process recovered from these unknown state.


Proper shutdown would consist of setting a shutdown flag to all potentially waiting threads, posting all semaphores before closing them, and waiting on child threads. If you time out waiting on the child threads to end, as a last resort, try DosKillThread, and exit hoping that the system can clean up the rest.

That's what I usually do.

But there are conditions where threads abort unexpectedly due to a program error (e.g. assert or trap). If this happens during the processing of PM messages, it sometimes will not recover.


Marcel
.

Relevant Pages

  • [PATCH 6/6] Simplify semaphore implementation
    ... The spinlock controls access to the other members of the semaphore. ... * many tasks are waiting for the lock. ... 'timeout' parameter for the cases without timeouts. ...
    (Linux-Kernel)
  • Re: Critique ThreadQueue class please
    ... ThreadQueue delete any remaining queued buffers. ... You need to communicate that to the caller. ... when this semaphore was caught it issued a Terminate ...
    (comp.programming.threads)
  • Re: WaitForMultipleObjects + Semaphore Makes Me Uncomfortable
    ... you which of the items you were waiting for got signaled. ... indication that the semaphore was signaled. ... The function modifies the state of some types of synchronization ... the documentation for the individual synchronization objects." ...
    (microsoft.public.win32.programmer.kernel)
  • Re: C++ multithreading: yet another Win32 condvar implementation
    ... until all objects become singalled that the thread is waiting on so ... Then thread_a enqueues two messages meant for threads_b_c and broadcasts the condvar which would increment the semaphore by two. ... Then before threads_b_c even get a chance to actually wait on the semaphore, thread_a enters the wait function and waits on the semaphore thus consuming a signal and spins back around on its predicate and waits again thereby consuming another semaphore signal... ... The basic scenario is that thread_a consumed its own signals which were meant for threads_b_c... ...
    (comp.programming.threads)
  • Re: Use of semaphores
    ... say hard disks or memory buffers. ... occurred to me that a semaphore could, in theory, also be used to ... Say having 10 max sized buffers, when any becomes occupied semaphore is ...
    (comp.programming)