Re: [boost] boost atomic question

Subject: Re: [boost] boost atomic question
From: Janek Kozicki (janek_listy_at_[hidden])
Date: 2010-04-30 12:58:34

Edouard A. said:     (by the date of Fri, 30 Apr 2010 18:36:13 +0200)

> 
> >This is for YADE, our software for discrete modelling.
> >
> >Imagine a std::vector of 125000 spheres:
> >
> >https://yade-dem.org/wiki/Screenshots_and_videos#Ball_Mill_-_125_000_sphere
> s
> >
> >it is currently parallelized with OPEN MP, but there are some global
> >locks in few places. Saying that each sphere is atomic (instead of
> >locking whole container) would solve the problem.
> 
> Actually you will only add problems if you do that. You need to use a
> concurrent container, not a classical containers with atomics variables.
> 
> First, atomic is more expensive than you think, to convince yourself of
> this, benchmark the two following codes:
> 
> int i = 0;
> while(i < 10 * 1000 * 1000)	++i;
> 
> and
> 
> atomic<int> i = 0;
> while(i < 10 * 1000 * 1000)	++i; 
> 
> Second, you will lock nevertheless because your memory entries will belong
> to the same cache line. You need to use a special allocator that makes sure
> that each entry doesn't overlap so that reading and writing to a slot will
> not result in false sharing.

yes, the cache line issue seems to be our problem right now.

> Third, wrapping a variable in atomic doesn't magically make your variable
> immune to the reader/writer problem (or other synchronization problems). You
> probably want access to your object to be atomic, in which case a container
> that guarantees that affectation to an entry is atomic is enough for you.
> Making your business logic reader/writer proof is generally more complex
> than a simple atomic<> wrapping.
> 
> All in all, I think that what you need is a concurrent_vector<T> not a
> vector<atomic<T>>.

The one from intel thread building blocks? Or another one? I don't
see it in boost, unfortunately (or I'm blind?). I would prefer to
avoid adding another large library to our dependencies. We will
consider it, though.

thank you for longer explanation. I am investigating the possibilities.

best regards
-- 
Janek Kozicki                               http://janek.kozicki.pl/  |