quote:

---

How useful would you find a string class or a linked list class that carried around a mutex that needed to be locked for every operation?

Very useful if I was sharing the string between processes, otherwise I'd wonder why they didn't use a critical section.

---

Actually it's kind of depressing to see people refer to strict Microsoft naming of MT primitives. I would say that mutex (MUTually EXclusive) is a wide concept including MS critical sections, MS mutex objects and MS semaphores. In other words critical sections are (a sort of) mutexes. And actually when reading a book strictly on concurrent programming, it would probably refer to them all as semaphores. So I wouldn't be to nit-picky about exact names...

quote:

---

But it's worse than that. If you pass a CWnd* from one thread to another, the second thread will not have access to the msg map for the WndProc... I'm not entirely certain what all the issues are, and they are notably evasive in the MSDN docs.
All I know is that I got a ton of assertion failures & crashes Can can work around it; you have to construct your CWnd in each thread you want to use it in from the native HWND. But then you're mutli-threading with Win32 handles not MFC objects.

If the only threading issue with MFC was a simple EnterCriticalSection(csMFC), it wouldn't be a big deal...

---

I'd say it's a big design-flaw in the code if you have more than one thread doing GUI-work.


Edited by - amag on February 8, 2001 9:37:30 AM

quote:

---

I''d say it''s a big design-flaw in the code if you have more than one thread doing GUI-work.

---

Like a msg pump for the WinProc in one thread, and a second thread for Dx rendering (think Dx & windowed mode)?

And I thought semaphores were distinctly different than mutexes in that they allowed multiple items concurrent access, while a mutex allowed only one? Or is that purely a M$ concept?

Magmai Kai Holmlor
- The disgruntled & disillusioned

quote:

---

Like a msg pump for the WinProc in one thread, and a second thread for Dx rendering (think Dx & windowed mode)?

---

Yes you are partly right, but I'd tend to see the message-pump as another Input-thread in this case, it doesn't do the actual rendering anymore, since that has moved to the DX-thread, right?


"And I thought semaphores were distinctly different than mutexes in that they allowed multiple items concurrent access, while a mutex allowed only one? Or is that purely a M$ concept?"

Actually a binary semaphore would allow only one access. The reason MS has separated the semaphore and critical section and mutex objects are simply effiency-reasons. The most commonly used semaphore is the binary and it can be greatly optimized by
using the CPU-instruction BTS (Bit Test and Set) (which indeed must be used by all mutex-primitives, but generic semaphores and mutex-objects require a bit more than that in order to work). Thus MS chooses to do a special implementation (which is perfectly sane, the opposite would be insane) for binary semaphores that they call critical sections. The same is with mutex-objects, since they allow inter-process synch, it would be too slow to put that in normal thread-synching primitives (although it is perfectly valid to use mutex-objects for thread-synchronisation), thus they add the mutex-object. All are specialised versions of the Concurrent Programming primitive semaphore. There are other primitive such as the monitor and the refined protected object that you can find in a language such as Ada 95 (not sure if it exists in Ada 83) and Java (using the synchronized specifier for methods). Those are not semaphores, but completly different primitives.



Edited by - amag on February 9, 2001 7:21:21 AM

Right, a mutex IS a semaphore, with the maximum count set to one.

Interesting thing about monitors: they''re impossible to implement in Win95, but you can do it in NT. I''m by no means an expert in this, but from what I understand, monitors allow any logical expression (i.e. non-synchronization objects) to be treated as a synchronization condition. The trick is, in order to implement one, you must have (in win32 land) "SignalObjectAndWait".

I don''t recall the specifics of why this is necessary, this was from my NT threads programming course. But this isn''t supported in win95, only in winnt. NT also has "CreateWaitableTimer", which is too damn cool, but totally unportable to 95 or 98. Bummer.

That''s because monitors support a type called a condition variable. Only threads waiting on a condition variable when it is signaled are wakened; if any threads then call wait immediately after the signal they still sleep. You usually must acquire a mutex prior to calling signal, and acquire a mutex before wait. The wait function atomically puts the thread to sleep and drops the mutex.

You can implement a condition variable in Win95, you don''t need WinNT''s SignalAndWait to do it (though it is a lot easier.)

I wouldn''t be too concerned about this though. Since Win32 event''s have memory, you can make minor mistakes, that would cost you on a condition variable, but would still work with events.