Re: why boost:shared_ptr so slower?
On Aug 25, 12:41 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
On Aug 25, 3:09 am, James Kanze <james.ka...@gmail.com> wrote:
On Aug 25, 2:50 am, Joshua Maurice <joshuamaur...@gmail.com> wrote:
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.
Actually, I was thinking about this more, and I was mistaken
(partially) in my first post. To accomplish atomic increment,
you need mutex-like acquire and release semantics, the
semantics people are used to from posix mutexes.
And what do you thing the implementations of Posix mutexes use
to provide those semantics? The implementations I know do so
without executing protected code (if there is no conflict); they
pretty much do an atomic increment or an atomic exchange at the
user level, and the same machine instructions are available to
any function willing to use a bit of assembler.
This is generally different than read and write memory
barriers, or fences, as I've seen the terms discussed in
context of the linux kernel (and other places). Acquire and
release semantics imply a global order on the acquiring and
releasing, necessary for atomic increment. There is no such
global ordering for read and write memory barriers as defined
by the linux kernel docs, which only offer conditional
visibility as I outlined in my first post.
I'm not familiar with the Linux kernel documents, but I do know
what the membar instruction does on a Sparc architecture. I
also know that on a Sparc, Solaris doesn't enter into kernel
mode in pthread_mutex_t unless there is contention; I believe
that this is true under Linux as well. (I've been told it is,
but I've not actually verified it myself.) Which means that
there are some sort of fence or barrier instructions which can
be used in non-priviledged mode to ensure the desired acquire
and release semantics.
[...]
PS: to add to the quagmire of this thread, I feel that the
term "thread-safe" when applied to a class or interface
without context and additional explanation material is like
calling a solution "bad", or "good", or "correct". All are
overly vague, and as a consequence, mostly devoid of useful
content.
Given that experienced people seem to disagree as to what it
means exactly, that's probably the case. With the difference
that with words like "bad" or "good", the vagueness is patente,
whereas with "thread-safe", everyone thinks they know what it
means.
--
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