On Sep 21, 2:19 pm, "Chris M. Thomasson" <n...@[EMAIL PROTECTED]
> wrote:
> [comp.programming.threads added]
> "James Kanze" <james.ka...@[EMAIL PROTECTED]
> wrote in message
> news:6edabaf2-df46-49b9-91b6-0dd5c312038d@[EMAIL PROTECTED]
> On Sep 13, 3:18 am, Bill David <billdavi...@[EMAIL PROTECTED]
> wrote:
> > > SUBJECT: How to make this program more efficient?
> > > In my program, a thread will check update from server
> > > periodically and generate a stl::map for other part of this
> > > program to read data from. Let's name the update method as
> > > doUpdate and stl::map read methods as getData and copyData.
> > > Since stl::map is not thread-safe, we should do
> > > synchronization by ourselves. A usable solution is to create a
> > > boost::mutex::scoped_lock object in all above methods to make
> > > the access to all methods synchronized. But since the doUpdate
> > > method will be executed periodically and the interval may be 1
> > > hour or longer, while all other parts can only read the
> > > stl::map, the above solution may do synchronization too much.
> > > We only need synchronization on all methods when we are
> > > doUpdating.
> > If there's any thread modifying the object, then all accesses
> > must be synchronized. Period.
> Did you know that readers threads can access data-structures
> without sync?
Not according to Posix, and not on many machines. Reading
without a sync will probably give you some value, but not
necessarily the last written.
> Or perhaps, any explicit sync whatsoever? No atomic RMW, no
> membars... Think about it. Virtually zero-overhead of reader
> threads indeed. Sounds to good to be true? Why? Perhaps I can
> clarify.
> > Given the usage pattern, it may be more interesting to use a
> > rwlock than a mutex, but this really depends on how long the
> > readers hold the mutex, and how many of them there are.
> Sure. For read-mostly access patterns, WHY use a rwmutex? Did
> you know that rwmutex can be totally suboptimal even in the
> presence of concurrent mutators?
And? A rwlock, even when acquired for just reading, ensures
memory synchronization.
--
James Kanze (GABI Software) email:james.kanze@[EMAIL PROTECTED]
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
|
