RickLH

In short - How can a second thread to determine if another thread is sleeping while waiting on an event to be set or if the thread abandoned the wait due to a timeout In Win32, this was a breeze since the wait function returns a code that indicates why the wait terminated. .NET's WaitOne only returns a bool, indicating whether or not the event was signalled during the wait period, which isn't what I need. How can I accomplish the same sort of thing in .NET

Here's some fragmentary pseudo code of what I'm trying to do

Code Block

Thread 1:

// Create an object 'o' that contains worker thread code.

// Add a client call back to that object.

// Insert a reference to the current thread into the newly

// created object.

// Add the object to a queue that will, after a short delay,

// execute that object's worker thread.

// 'wait' is an AutoResetEvent and resides in the newly created object.

// Go to sleep until either the object's worker thread sets the 'wait'

// event or the wait times out.

// The client callback will only be invoked if the wait

// event times out. Otherwise, assume that the worker was able

// to complete its work before the time out expired and

// the client can return the worker's result directly without

// making use of the callback.

o.clientCallBack = new ClientCallBackDelegate( methodToCall );

AddToExecuteQueue( o );

o.wait.WaitOne( timeOutInMilliseconds, false );

// Return to the caller, passing back the return value

// from the object which will be a return value if the

// object's worker thread has completed or a code that

// indicates that a callback notification will happen

// when the worker does finally complete.

return o.Results;

Thread 2:

// The worker has executed a bunch of code and now the worker

// must determine if the client caller is still waiting or if

// the client caller gave up.

// If still waiting then put the worker's results where the client

// can find it and return it.

// If the client gave up then call the client's callback notification

// delegate instead.

Results = theResultsFromTheWorkerThread;

if ( 0 != (threadCaller.ThreadState & ThreadState.WaitSleepJoin))

{

wait.Set();

}

else

{

callClientNotifyDelegate( Results );

}

The problem is this line:

if ( 0 != (threadCaller.ThreadState & ThreadState.WaitSleepJoin))

It is evaluating as true even though the the event 'wait' has timed out and the client thread has started executing again. The debugger says that threadCaller.ThreadState is equal to Background (it's a UnitTest so that's an entirely reasonable state).

So - how can the worker thread code determine the calling thread's wait state or, failing that, is it possible to extract the 'wait event has timed out' information from the AutoResetEvent


Re: .NET Base Class Library How to determine if a thread is waiting on an event?

eradicator

In Win32, this was a breeze since the wait function returns a code that indicates why the wait terminated. .NET's WaitOne only returns a bool, indicating whether or not the event was signalled during the wait period, which isn't what I need. How can I accomplish the same sort of thing in .NET

I believe if WaitOne returns false, that means it timed out. Isn't that analogous to one of the Win32 return codes you speak of You're throwing away the return value currently, but maybe you should make use of it in your logic like you supposedly would have used the Win32 return value.





Re: .NET Base Class Library How to determine if a thread is waiting on an event?

RickLH

Because of scheduling concerns, I went ahead and used Win32 techniques to solve the issue which worked just fine but I'd rather have solved the muti-threading issue staying completely within .NET.

As for your suggestion - that's certainly a good thought but it only works in the case where there are only two threads involved. Sadly, the production code can have a number of threads that may set the event in order to restart the first thread.

1st thread sets bool to true then waits.

Case 1: 1st thread is still waiting when 2nd thread sees bool is true. 2nd thread doesn't know if 1st is still waiting or if 3rd thread set the event.

Case 2: 1st thread times out before 2nd thread looks at bool. This clears bool. 2nd sees bool is false and knows 1st timed out.

Case 3: 1st thread times out but the scheduler takes away its time slice before it completes writing a false to the bool. 2nd thread incorrectly sees a true and incorrectly acts as though the 1st thread was still waiting.






Re: .NET Base Class Library How to determine if a thread is waiting on an event?

nobugz

The WaitForSingleObject() API function can only return two distinct non-error values. WaitOne() returning a boolean is of course equivalent. There are several mistakes in your code. Firstly, using ThreadState to determine whether thread 1 is waiting can't work. A thread is almost always in a WaitSleepJoin state. If it wasn't, it would be burning 100% CPU time. You would be seeing it blocking on some kind of I/O operation. Secondly, there's a gaping race condition in your test. First checking if is blocked, then setting an event leaves you wide open to the thread becoming unblocked right in between.

You'll need a much more advanced lock design. I'm not brave enough to offer you one.