Re: STL Queue and multithreading
On Nov 10, 10:43 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
On Wed, 2010-11-10, James Kanze wrote:
On Nov 9, 8:46 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
Goran Pusic <gor...@cse-semaphore.com> wrote:
I would like to minimize the mutex usage
Minimize? Why? What performance numbers you have to back that?
It's a well-known fact that software mutexes are extremely
slow and can seriously impact performance in situations where
the data container needs to be accessed a very large amount of
times very fast.
Beware of "well known facts" that aren't backed by actual
measures. I don't know about Windows, but under Solaris, an
uncontested pthread_mutex_lock is not significantly slower than
any of the alternatives, at least in the benchmarks I've run.
What alternatives do you mean?
I was thinking of various lock free algorithms, using atomic
modifications (CAS, atomic increment, etc.). These all require
some sort of fence or membar, which is all that
pthread_mutex_lock does if there is no contention.
I think the proper question here is
more like "what useful work could I have done in the time I used to
lock and unlock mutexes"?
*IF* there is a performance problem, the question is: what are
the alternatives, and will they be faster? But that's a big if.
But the answer is (you surely agree): "If it really matters to you,
benchmark".
Well, I'd start by assuming that it doesn't matter, until proven
otherwise:-). Even benchmarking is unnecessary extra work if
the code is fast enough when written normally. (But of course,
if it isn't, you don't do anything until you've profiled.)
--
James Kanze