Re: why boost:shared_ptr so slower?
On Aug 25, 2:50 am, Joshua Maurice <joshuamaur...@gmail.com> wrote:
On Aug 23, 6:47 am, Sam <s...@email-scan.com> wrote:
Which is why I said "producing a result that's visible to
all threads..."
gcc manual, section 5.47, under the description of atomic
functions, states the following:
In most cases, these builtins are considered a full
barrier. That is, no memory operand will be moved across
the operation, either forward or backward. Further,
instructions will be issued as necessary to prevent the
processor from speculating loads across the operation and
from queuing stores after the operation.
I interpret this as stating that the results of these atomic
functions will be immediately visible to all other threads.
(Now, the GCC manual is not as clear as I'd like, so I'm not
the most comfortable posting this, but I think I'm right.
Correct me if I'm wrong.)
I think you're right.
I'm not sure if you're misspeaking or actually
misunderstanding. When the term "barrier" is used in the
context of threading, the results are not immediately visible
to other threads, nor even visible on the next matching
barrier. Barriers are conditional visibility. Ex:
//static init
a = 0;
b = 0;
int main()
{ //start thread 1
//start thread 2
}
//thread 1
a = 1;
write_barrier();
b = 2;
//thread 2
cout << b << " ";
read_barrier();
cout << a << endl;
Without the barriers, you may see any of the four possible
outputs:
0 0
0 1
2 0
2 1
With the barriers in place, this only removes one possible
output, leaving the three possibilities:
0 0
0 1
2 1
The definition of visibility semantics is effectively: "If a read
before a read_barrier sees a write after a write_barrier, then all
reads after that read_barrier see all writes before that
write_barrier."
To nitpick your quote:
I interpret this as stating that the results of these atomic
functions will be immediately visible to all other threads.
It is not the case that the write will be immediately visible
to all other threads. Moreso, even if the other thread
executes the correct barrier instruction(s), that write may
still not be visible.
That's a very important point. Without going into details,
there is nothing thread a can do which will force thread b to
see the change. When we say that the barrier makes the change
immediately visible to all other threads, we really mean "to all
other threads that want to see it, and take the necessary steps
to do so". It takes a collaborative effort.
If you want guaranteed visibility, use mutexes. However, even
a mutex in one thread does not guarantee that the write
becomes immediately visible to other threads. The other
threads still need to execute the matching "mutex lock"
instruction(s).
Barriers, used correctly, will also work, but as you say, they
need to be present in all concerned threads.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34