will it be dangerous that more than one threads are sharing one variable? what would happened if two or more threads are trying to operate one variable at the same time? :confused: any help would be greatly appreciated~~ :D
Printable View
will it be dangerous that more than one threads are sharing one variable? what would happened if two or more threads are trying to operate one variable at the same time? :confused: any help would be greatly appreciated~~ :D
> will it be dangerous that more than one threads are sharing one variable?
Variables which can be modified in a single instruction are OK - say an integer
Two threads can read and write that as much as they want, and nothing unusual is going to happen.Code:int shared = 0;
One thread doingCode:char *shared_buff = NULL;
shared_buff = new char[10];
and another thread doing
delete [] shared_buff;
is on the other hand a recipe for big disasters.
Look up critical sections / semaphores / mutex for info on how to guard concurrent access to shared data.
thank you,SalemQuote:
Originally Posted by Salem
if one thread are doing "shared++;" when another thread are doing "shared=10;", two are trying to operate shared at the same time, then what is the value of shared? :confused:
++ isn't an atomic operation
ho.......what if doing "shared = 10;" and "shared = 1;" at the same time?
I have a simple Windows MT tutorial which covers basic synchronisation starting here.
i will read it carefully. thanks a lot ~~~~~~ :)Quote:
Originally Posted by adrianxw
One of them will be executed a little later, that one will prevail.Quote:
ho.......what if doing "shared = 10;" and "shared = 1;" at the same time?
>>> what if doing "shared = 10;" and "shared = 1;" at the same time?
On a single processor system, only one thread will be running, whichever thread runs second will set the result. On a multi processor system, both are likely to set the value in their own local cache, whichever cache flushes last will set the value.
I have to disagree.Quote:
Originally Posted by Salem
All multithreaded access to variables should be protected by synchronization primitives - here's why.
There are a couple of problems that can arise when using this construct. The compiler is free to optimize (what appears to be) read-only access to memory by placing the memory contents into a CPU register. While one thread uses the value within the register, another thread can change the value within memory which the first thread may never see.
This can be overcome on single x86 processor machines by using the volatile keyword. This tells the compiler to not optimize access to an object (reads and writes go directly to memory).
It is true that reads and writes to aligned, CPU-sized data, on an x86 is an atomic operation. (I've also read that this is only true for PII's or higher.) This is not necessarily true on other CPUs, in which case using volatile doesn't help since a read or write operation could be pre-empted.
On SMP machines, volatile doesn't help the situation either since each processor has it's own memory cache. The processors within an SMP machine are only required to synchronize their caches on a memory barrier. Memory barriers occur when certain instructions are executed.
Using a synchronization primitive/function will typically execute one of these instructions and cause a memory barrier. This is necessary so that any cached modifications to an object on another processor are seen by the current processor.
So in summary, synchronization primitives/functions (which cause memory barriers) should be used in order to implement correct synchronization in all environments.
Synchronization and Multiprocessor Issues
Interlocked Variable Access
gg
More for your reading pleasure:
comp.lang.c++.moderated - volatile, atomic variables & multithreading
gg
synchronization, i will conquer it this weekend.
Unlikely. It will suck up the weekend and still leave you with tons of things uncovered :-)Quote:
Originally Posted by Hermitsky