Re: why UI gets hangs
Joseph M. Newcomer wrote:
See below...
On Mon, 24 Mar 2008 18:47:59 GMT, Dan Bloomquist <public21@lakeweb.com> wrote:
Joseph M. Newcomer wrote:
UINT Thread( LPVOID pParam )
{
...
for( long i= 0; ; ++i )
//This is the worker loop, it is doing real work.
{
...
//Now it has progress data for the GUI thread
//if that thread is ready for another message
//it will post it.
if( strct.bTReady )
{
strct.strT.Format( _T("Test This %d"), i );
::PostMessage( *strct.pDlg, ID_CHECK_THREAD, 0, 0 );
strct.bTReady= false;
}
}
}
GUI updated. In that light, do you see a problem with the way I use the
semaphore strct.bTReady?
****
It isn't a semaphore; it is a bool variable.
The wiki author calls it a 'binary semaphore', better known as a mutex.
http://en.wikipedia.org/wiki/Semaphore_(programming)
****
I see no similar example in that article. Note that what you have done is not what is in
the article, or even close to what the article describes. In order to follow what the
article does, you need an atomic operation (InterlockedCompareExchange) and you have to
spin-wait; you do not wait, you just skip sending the message. That is not a semaphore,
not even close to a semaphore; it is just a boolean flag.
Ok, officially I concede it should not be called a semaphore as I have
not wrapped it in a class with waits. The wiki page needs fixing:
"The simplest kind of semaphore is the "binary semaphore", used to
control access to a single resource, which is essentially the same as a
mutex. A binary semaphore is always initialized with the value 1. When
the resource is in use, the accessing thread calls P(S) to decrease this
value to 0, and restores it to 1 with the V operation when the resource
is ready to be freed."
If two threads are running this code, and both get to instruction [1], BOTH of them pick
up strct.bTReady. Or, on a uniprocessor, thread A executes [1], gets preempted, and the
other thread runs and executes [1]. Both see it is TRUE.
Not the way I wrote it. See below...
Both proceed to spend a lengthy
amount of time formatting data, stepping on top of each other in potentially disastrous
ways, and then both set it to FALSE at step [2].
Ok, now you have two worker threads working on the same data in the same
way? Sure, that won't work. I never dreamed it would.
This cannot possibly work! While it is
less likely to fail on a uniprocessor, it will still fail eventually.
Not what I wrote. The worker thread affects the shared data. The GUI
thread has no access as it never got a message to process. The worker is
done, sets the flag and sends a message. (I did get that out of order in
the example. It would have lead to a failure eventually. But that's a
bug.) Now the worker thread will not touch the data or the flag again
until the GUI member uses the data and resets the flag.
A hyperthreaded
processor will increase the chances, a multicore processor will increase the chances even
more, and with multiple threads using it on multiple cores, it rapidly becomes a
certainty.
It won't fail because the worker thread excludes its own access. It
won't touch the data until the GUI member says it is done with it. The
only thing that could go wrong is if the message got lost.
I'll leave the following as it is an interesting account of the
evolution of threads. I read all your stuff.
Now, if you had done
if(!InterlockedCompareExchange(strc.bTReady, FALSE, TRUE)) /* do nothing */ ;
then you would have a spin-lock which would actually work, and you could safely use it.
Lousy from a CPU utilization viewpoint, but at least correct. But what you have is not
even a mutex, because it does not guarantee exclusion, and it is not multiprocessor safe.
If you had done
if(InterlockedCompareExchange(strct.bTReady, FALSE, TRUE))
{
... code as above
}
you would still have an information-losing transformation but it would at least not have
the failure potential of the current code, which is completely unsynchronized.
You can't take a random piece of code and call it a "mutex", because a "mutex" has very
specific meaning. After Dijkstra's work, other researchers introduced the concept of what
we now call a "mutex", which is a mutual exclusion primitive with recursive acquisition
semantics. A mutex is quite different from the "binary semaphore", because a semaphore
has no recursive acquisition semantics. A CRITICAL_SECTION is named after what Dijkstra
had called the *code* guarded by the semaphore, but as used in Windows it means "a very
efficient mutex" because it has both recursive acquisition semantics and avoids calling
the kernel for scheduling until a counted spin-lock expires. The notion of timed waits was
also introduced after Dijkstra; he never quite approved of them because he thought a
properly-designed system would not require a timeout of any sort; and strictly speaking,
the CRITICAL_SECTION uses the "timeout" as an internal way of obtaining efficiency while
still maintaining the philosophical correctness of the original mutex (or, if you ignore
recursive acquisition, semaphore) concept.
One of the other interesting challenges we had (which was part of my PhD qualifier exam)
was the multiple-reader-single-writer problem, which the kernel implements as the
Executive Resource (ERESOURCE) type. You can do it with a lot of convoluted programming
with mutexes (mutice? mutices?) but it isn't straightforward. We have no user-level
equivalent of this.
You do not have a semaphore,you do not have a mutex, you have an unprotected and
unsynchronized BOOL variable. Nothing more (and, the code is basically incorrect).
I don't see the flaw. But I'll never call a flag a semaphore again. (pun
intended :)
****
I would think any object that is used as a signal between threads would
qualify as a semaphore.
****
No. Dijkstra very carefully specified how a semaphore behaves, and if it doesn't behave
like that, it is NOT a semaphore. Those of us who worry about synchronization would never
recognize the code you wrote as being anywhere vaguely close to the concept of semaphore.
The word has a very specific semantic meaning. Otherwise, you could use an Event as a
"semaphore", which a number of beginners try to do, and it always fails, because and Event
is NOT a Semaphore. The word "semaphore" does NOT mean "any arbitrary signaling
mechanism", it very specifically means "a counted exclusion object that blocks the thread
when the count is 0; a wait operation decrements the count, and a release operation
increments the count". Dijkstra called the wait operation "P" and the release operation
"V"; we call them WaitForSingleObject(..., INFINITE) and ReleaseSemaphore(...,1, NULL) if
we want to model Dijkstra's original semaphores.
I took one of my Operating Systems classes from Nico Habermann, who was one of the best
students, or perhaps THE best student, that Dijkstra had. (Nico was a friend, and died
far too young of a coronary, apparently after returning from jogging. I worked with him
on several projects, and he was head of the Computer Science Department at CMU for many
years while I was there and long after I left. He also created the PhD qualifier exam I
struggled with, but years later told me I had done the best job he'd ever seen).
You can't take some random concept (such as setting a BOOL) and call it a "semaphore".
http://pages.cs.wisc.edu/~remzi/Classes/537/Fall2005/Lectures/lecture6.ppt
See "Producer/Consumer: Single Buffer". It is the same concept but
without waits. But it is not random.
****
In rereading it, I see that the Sleep() is
not part of the test loop, but now you have a situation in which it will not update unless
the other thread has processed the data, which means that you will lose information by not
sending it at all. If your system is redundant enough that you can afford to lose
information, then it works, but if you need reliable communication by which everything you
want to send is received, it doesn't work.
Sorry for the confusion. I thought what I was doing was clear in the
original post. It was an experiment to purposefully break it. One, by
swamping the GUI thread and second, by letting the GUI thread at the
data while it was changing.
****
You didn't actually create a reliable situation during which the concurrent access could
be achieved. To really break it, you would need to use two threads trying to write the
string, and you could significantly increase the chances of this by running it in any
multicore processor.
In the example I commented:
//if( strct.bTReady )
And noted that in the text. I'd imagine if I waited long enough the GUI
read would have caught CString with invalid data. But as important, it
would swamp the GUI thread and the app would not respond. Even worse,
the OS sees the app possessing messages so doesn't see it as 'not
responding'. Should be tested on vista.
****
And yes, of course it would have to be more elaborate to ensure data is
not lost.
****
And rather important in a lot of cases!
****
To wit. I have one dictionary that lives in a message thread. You can
have multiple views running worker threads that do spell checking. The
user can right click, spell check or thesaurus words while the view is
spell checking and and marking misspelled words.
I do know how important it is to make sure everyone behaves.
Best, Dan.