Two threads walk into a loop. . .

[paradoxresolved]

Two threads enter into the following loop.

while(m_bLocked) {}
m_bLocked = true;

// where m_bLocked is a bool datatype.

A third thread turn m_blocked to false. Is it possible for both threads to get to the m_bLocked = true statement at the same time?

During the period of time that one thread completes the m_bLocked = true statement, would it be possible for the second thread to escape the loop?

[Codeplug]

>> Is it possible for both threads to get to the m_bLocked = true statement at the same time?
Anything is possible when you don't use proper synchronization. All threads may exit the loop - or no threads may exit the loop.

gg

[paradoxresolved]

What do you mean by "proper synchronization?" I've been trying to find a book on this topic, or at least a decent online tutorial, but I'm having trouble with it. Java and C# give examples that lock functions and objects with a synchronized keword or lock keyword, but I'm using C++ on VC6, so I'm trying to recreate something on that level.

Can you direct me to a good online tutorial or book that covers synchronization for C++?

[Codeplug]

Your main documentation is here: http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx

If you describe what it is you are trying to accomplish then we can give some guidance on that specifically as well.

gg

[Paul McKenzie]

What do you mean by "proper synchronization?" I've been trying to find a book on this topic, or at least a decent online tutorial, but I'm having trouble with it. Java and C# give examples that lock functions and objects with a synchronized keword or lock keyword, but I'm using C++ on VC6, so I'm trying to recreate something on that level.

Can you direct me to a good online tutorial or book that covers synchronization for C++?

I'll be blunt. Writing applications that do proper synchronization in C++ takes experience and a whole different ballgame than writing single-threaded apps.

It isn't something you pick up in a day or so reading a tutorial. Yes, you get to know what the synchronization objects do, but then it's up to you to know the right synchronization objects to use, when to use them, how to use them, what problems might arise if you use one over the other, and the most difficult thing in many respects -- debug applications that have problems with synchronization. The latter being the big one. It may take you weeks to get your app running correctly, and even then, you may still have problems arise that you may have to debug.

Just to let you know that this isn't something trivial -- there are many companies that will not hire a programmer if they have no experience in writing multithreaded apps, regardless of how much experience they have in writing single threaded (i.e. "regular") apps or how good they are in C++. Whether this is fair or not, that's a matter of opinion, but this is basically how the corporate computing world believes in the difference between writing single-threaded apps as opposed to multithread apps.

Regards,

Paul McKenzie

[Amleto]

the op might want to consider using something slightly newer than VC6 as well

[0xC0000005]

No C++ help from me... am I the only one who wants to hear the punchline to the subject?

[paradoxresolved]

What a nightmare! I appreciate the frankness of the responses. The more I experiment, the more I'm gathering that this is a rough subject. I can put together code that reduces the odds of data being altered simultaneously, but in theory I can't eliminate the possibility all-together - precisely because of the original question of this *ehem* 'thread'. I agree about the debugging stuff. Maybe 'nightmare' is too light a word for it.

My questions boil down to this:
1) What book would you recommend for the subject of multithreading in C++? I'm having a hard time finding one in the usual bookstores.

2) What is the best coding environment to debug multithreaded programs? My experience is almost exclusively with VC 6.0, and it doesn't seem to have any tools that I'm aware of that are designed to specifically help debug synchronization issues. Until recently, I've never had a need to upgrade.

I appreciate your help, all.

[Paul McKenzie]

I can put together code that reduces the odds of data being altered simultaneously, but in theory I can't eliminate the possibility all-together - precisely because of the original question of this *ehem* 'thread'. I agree about the debugging stuff. Maybe 'nightmare' is too light a word for it.

The debugging can get very tricky. One reason is that you cannot consistently duplicate the error. Sometimes you can spend days, and not see any threading issue, and then that one odd time on that one day in the week, the runtime error pops up. Then when you're ready to debug, you can't duplicate the issue again.

You may be able to get lucky and duplicate a problem consistently, making it somewhat of an easier chore to identify what's wrong, but then the next step -- how to fix that problem. Do you introduce a mutex, semaphore, critical section, etc.? If you do, how does that affect other code?

Those are some of the reasons why a lot of companies will not consider hiring anyone that does not have a good grounding in programming multithreaded apps. It is just too big and important of a topic to start on-the-job training. In many of these places, if Stroustrup himself were to walk into an interview and claim he never did multithread programming , he would be shown the exit.

As to your problem, you can start looking for static variables, re-entrant code, the same object instance used in different threads, etc. Identify those places in your code. Once you identify them, then think of what needs to be protected. Then figure out what set of synchronization objects you need to use to protect those areas.

My questions boil down to this:
1) What book would you recommend for the subject of multithreading in C++? I'm having a hard time finding one in the usual bookstores.

You can try this:

http://www.amazon.com/Multithreading.../dp/0201442345

http://www.amazon.com/Concurrent-Pro...ref=pd_sim_b_3

I haven't reviewed those books myself.

You can also try Unix books. Even though UNIX/LINUX is a different OS, you can still get a good grounding in MT development by reading various UNIX tomes on multithreaded programming.

2) What is the best coding environment to debug multithreaded programs? My experience is almost exclusively with VC 6.0, and it doesn't seem to have any tools that I'm aware of that are designed to specifically help debug synchronization issues. Until recently, I've never had a need to upgrade.

Well, you can try the old "run a release build built with debug info", and just let it run. If it's a program where you can let it run forever without user-intervention, just let it run until it crashes (hopefully it will crash). Then when it crashes, you get a look at the call stack, variables, etc. see what variables are wrong or corrupted, and make decisions from there (which as I stated, takes some experience in itself).

Then there are these links:
http://msdn.microsoft.com/en-us/library/ms164746.aspx

http://www.drdobbs.com/199200938;jse...OSKHWATMY32JVN

I like the advice in the link above, where it states that your app should run without error in single-thread mode first. If you have a problem even when running on one thread, don't even think about adding synchronization until those problems are worked out.

Regards,

Paul McKenzie

[Arjay]

For detailed info on processes, threads and synchronization objects, check out Programming Applications For Microsoft Windows by Jeffrey Richter.

This book gives a great introduction to processes, threads and m/t fundementals.

The book also talks about the concept of a shared resource (i.e. a resource such as a int, string, file, etc. shared between two or more threads).

In simple terms, if all the threads accessing the shared resource have only read only access, then no synchronization is required. However, if at least one thread accesses the shared resource for writing, then BOTH the read and write operations must be synchronized.

What is synchronization? Synchronization simply prevents a shared resource from being accessed by more than one thread at a time. In other words, threads attempting to access the resource are serialized so that one one thread can gain access at a time. When a thread gains access it is said to "acquire a lock" forcing other threads attempting to gain access to wait. When the thread holding the lock is finished accessing the resource, it releases the lock which allows the next waiting thread to acquire the lock.

This concept is a bit difficult for m/t beginners to understand because they often hear that a multithreaded app can do work in a concurrent manner - well it can (and does), provided that individual threads aren't accessing shared resources. If threads need to access a shared resource, then this access must be serialized. One might think that synchronization is a bottleneck and offsets the benefits of concurrency - while technically this is true; however, in a properly designed m/t app locks are held for a minimum amount of time, so there is very little thread contention (i.e. threads that have to wait to acquire a lock).

How is Syncronization Achieved? In Windows, thread synchronization is achieved using a syncronization object (or primitive) such as a critical section, mutex, or semaphore to name a few. One of these objects is created, initialized and is used to protect a particular resource.
Beginners sometimes miss understand how a resource gets protected and think that the synchronization object gets somehow attached to the resource. This isn't the case. What really happens is that the synchronization primitive becomes a form of 'gate keeper' that blocks the execution of lines of code that actually access the resource.

...to be continued...

[GCDEF]

No C++ help from me... am I the only one who wants to hear the punchline to the subject?

You'd think one of them would have seen it.

[Lindley]

A third thread turn m_blocked to false. Is it possible for both threads to get to the m_bLocked = true statement at the same time?

It sounds to me like what you want is conditions and signals. The exact syntax depends on which threading library you're using----Windows Threads, pthreads, Boost::Threads, standard threads (certainly not this one with VC6, it's far too old), etc.

Here's some pseudocode which could be adapted to any of the libraries:

Threads 1+2:

LOCK thismutex
while (m_blocked)
    WAIT blocked_condition, unlocking thismutex during wait
m_blocked = true;
do some work // alternatively, this could be outside of the mutex lock depending on specifics
UNLOCK thismutex

Thread 3:

do some work
LOCK thismutex // important, this must be the same mutex object as above
m_blocked = false;
SIGNAL blocked_condition
UNLOCK thismutex

[paradoxresolved]

Thanks for the help guys. Your responses are great! The issue seems a little clearer. I think I've gotten at least a foothold on the topic, and I can hopefully build on it with experience. I tried using critical sections in my project, but I'm fairly sure I end up with a deadlock early on. I'm gonna muddle through it for a while and see if I can nail it down.

I found a copy of Multithreading Applications in Win32, so I'll start reading through it shortly. I might pick up a copy of some of the other books you suggested as well.

Thanks again.

Oh, and sorry, there wasn't really a punchline. Let me know if you can think of one though.

[GCDEF]

Oh, and sorry, there wasn't really a punchline. Let me know if you can think of one though.

http://www.codeguru.com/forum/showpo...6&postcount=11

[0xC0000005]

Oh, and sorry, there wasn't really a punchline. Let me know if you can think of one though.

Two threads walk into a loop. Thread 1 says to Thread 2: "Who was that critical section I saw you enter last night?" Thread 2 says: "That was no critical section, that was my mutex!" bada booom!