On Sep 1, 7:56 am, Pete Becker <p...@versatilecoding.com> wrote:
On 2008-09-01 03:34:02 -0400, NvrBst <nvr...@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)
I'm still fairly confidant that it would be safe for the given
situation. The Queue.Sychronization(Queue<T>) will sychronize a Queue
as said before, which is definally needed for most multithreaded
situations, however, for this specific situation I still think it's
safe. Before I was talking about a single processor, which I'm 100%
confidant it's fine, but I still think it's fine for multiple
processors. The only way it wouldn't be safe in a multle processor
environment is if the push's write to the CPU Cache on all processors
when it add's an element, which I don't think it does; or if the other
CPU Cache's are somehow updated by the Queue's "Push". Maybe I am
over my head, but the problem your trying to tell me is I think:
Thread A) Queue is Empty, Push's Element, Increments Version,
Increments Size, ??Updates 2nd CPU Cache??("B" starts before the "??")
Thread B) Reads Size as 1, Pop's Element, but CPU Cache for _array[0]
was cached previously returning garbage, Increments Version, Decrments
Size.
What I assumed was that the CPU Cache Misses, and would fall through
to reading it from RAM (thus getting correct element), or that .NET
would see Queue version has changed and CPU Cache would just be
initally bypassed, or that there was a shared Cache and each CPU cache
goes to the main cache (which is definally updated in the above
situation) to make sure it's valid. I don't know for sure, but, I
still believe it's safe for the given situation.
All this is .NET Framework, C#, Queue<T> - not C++ deque. My
computers are single processors which might be why I have never run
into the problem personally, but it will be something I keep in mind
for if I do run into a crash I can't explain :) Thanks.