Re: How to make this program more efficient?
On Sep 21, 2:19 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
[comp.programming.threads added]
"James Kanze" <james.ka...@gmail.com> wrote in message
news:6edabaf2-df46-49b9-91b6-0dd5c312038d@d1g2000hsg.googlegroups.com...
On Sep 13, 3:18 am, Bill David <billdavi...@gmail.com> 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@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