Re: std::deque Thread Saftey Situtation
On 2008-09-01 03:34:02 -0400, NvrBst <nvrbst@gmail.com> said:
No way the popping thread can atempt to access the 1st element when it
actually isn't avaliable because it'd read size as "0".
That's not the case. You're assuming that a second thread will see data
changes in the order in which the first thread makes them, and that
isn't the case unless you intervene to sychronize the two threads. In a
multi-threaded application running on a single processor that
assumption is valid, but for general threading it isn't. When there are
multiple processors running multiple threads, each processor has its
own memory cache, and writes to one cache aren't automatically
coordinated with reads from another cache. Seeing a 1 for the size
doesn't mean that the contents of the element that was written have
also been transferred. You have to ensure that all newly written data
has been transferred to the cache for the processor that's reading the
data, and you do that with a mutex or a conditon variable.
Let me be blunt: you're in over your head here. Java and C# make it
look like it's easy to write multi-threaded applications, but they just
paper over the complexities and make it easy to write an application
that works just fine until it crashes, which might happen immediately,
and might happen six months from now. Writing fast, robust
multi-threaded applications requires top down design, and can't be done
merely with libraries.
Get a good book on multi-threading. Dave Butenhof's "Programming with
POSIX Threads" would be a good place to start. It's about POSIX, but
the concepts are pretty much the same everywhere.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)