[comp.programming.threads added]
"James Kanze" <james.kanze@[EMAIL PROTECTED]
> wrote in message
news:6edabaf2-df46-49b9-91b6-0dd5c312038d@[EMAIL PROTECTED]
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?
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?
[...]
|
