Re: Waiting on a Thread - Revisited

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Charles Law (blank_at_nowhere.com)
Date: 05/27/04 

Date: Thu, 27 May 2004 16:35:03 +0100

Hi Jon / Alex

Hmm. I know you're right ... but ...

I deliberately kept the whole 'read message / update UI' thing inside the
SyncLock construct because it served as a way of pacing outgoing messages.

Messages have to be sent out synchronously, and the polling thread is
capable of adding messages to the queue much faster than they can be sent.
Therefore, locking the queue whilst the message was being sent seemed a
convenient way of preventing a backlog of messages from building up in the
queue. However, when the user clicks something, their request takes
precedence over the background processing, so it is legitimate to insert the
message at the head of the queue and not have to wait.

Can you think of another way round this?

Charles
[If my spelling has started to awry it is because I have started using
OE-QuoteFix, and now the spell checker always passes, regardless of spelling
mistakes.]

Jon Skeet [C# MVP] wrote:
> Charles Law <blank@nowhere.com> wrote:
>> Ok, I'm back. Who said this was going to be easy (actually, no one, I
>> think).
>>
>> As usual, it's not as straight forward as I am going to describe,
>> but this illustrates the problem.
>>
>> I have two threads: the UI thread and a polling (worker) thread. The
>> polling thread goes round and round updating the UI with information
>> it reads from a serial port, based on messages it reads from a
>> queue. Before it reads from the queue, it gets a lock on it
>> (SyncLock) to synchronise adding and removing items. If the queue
>> contains a message it is removed, the serial port is read, the UI is
>> updated, and the lock is released (End SyncLock).
>
> I think I can see what is coming...
>
>> The UI sits happily, displaying the latest information.
>>
>> Because the polling thread is not the UI thread (obviously) it can't
>> just stuff things onto the screen. So, when it updates a textbox,
>> for example, it uses a delegate and calls Textbox1.Invoke. Great ...
>> fine, so far.
>>
>> Now, the user comes along (bless him), and clicks a button. This is
>> the signal that a message must be added to the queue. So, the UI
>> calls a method to add a message to the queue. Before accessing the
>> queue, the UI thread gets a lock on the queue, adds its message,
>> pulses the queue, and releases the lock. Still sounding good.
>>
>> However, when the UI thread trys to get the lock (SyncLock again) it
>> can't get it straight away, because the polling thread has a lock,
>> and is about to update the UI. Therefore, the UI thread waits
>> patiently for the lock.
>>
>> The polling thread, meanwhile, goes to update the UI. It finds it is
>> not on the UI thread, so sets up the delegate and calls Invoke ...
>> and is never heard from again.
>
> Indeed.
>
>> Invoke hangs because it is now trying to marshal onto the UI thread,
>> but the UI thread is waiting on a lock that the polling thread
>> holds, so we have deadlock.
>>
>> Over to you Jon / Cor / anyone :-(
>
> Well you've done a first rate job of analysing the problem. All you
> need to do now is move the call to the UI update out of the lock, and
> you're home free :)
>
> Limit yourself to only holding the lock while you absolutely have to -
> for interacting with the queue. When you've read from the queue,
> release the lock and *then* do whatever you need to with the object
> you've just fetched, eg update the UI.

Quantcast