如何提高这个程序的效率？ [英] How to make this program more efficient?
问题描述
主题：如何提高这个程序的效率？
在我的程序中，一个线程会定期检查服务器的更新，并且
生成一个stl： ：映射该程序的其他部分以从中读取数据。
让我们将更新方法命名为doUpdate和stl :: map读取方法为
getData和copyData 。
由于stl :: map不是线程安全的，我们应该通过
自己进行同步。一个可用的解决方案是在所有上述方法中创建一个boost :: mutex :: scoped_lock
对象，以便访问所有方法
synchronized。但由于doUpdate方法将定期执行
，间隔可能是1小时或更长，而所有其他
部分只能读取stl :: map，上面解决方案可能会同步过多
同步。当我们进行更新时，我们只需要在所有方法上同步
。
那么是否可以提高这个程序的效率？
我曾经想过一些其他的解决方案，如添加一些更新标志。
但它不安全，因为当以下
部分读取方法正在执行时，stl :: map可能会更新。并且旗帜上的操作可能会被其他线程中断。
9月13日，3：18 am，Bill David< billdavi ... @ gmail.comwrote：
主题：如何提高这个程序的效率？
在我的程序中，一个线程会定期检查来自服务器的更新
并为其他部分生成一个stl :: map这个
程序从中读取数据。让我们将更新方法命名为
doUpdate和stl :: map read方法为getData和copyData。
由于stl :: map不是线程安全的，我们应该自己做同步
。一个可用的解决方案是在上述所有方法中创建一个
boost :: mutex :: scoped_lock对象，以使
访问所有同步的方法。但由于doUpdate
方法将定期执行，间隔可能是1
小时或更长时间，而所有其他部分只能读取
stl :: map，上面的解决方案可能会做太多的同步。
我们只需要在所有方法上同步
doUpdating。
如果有任何线程修改对象，则必须同步所有访问
。期。鉴于使用模式，使用rwlock比使用互斥锁可能更有趣，但是这个
实际上取决于读者持有互斥锁的时间长短，以及
其中很多都有。
那么是否可以提高这个程序的效率？
可能。探查器在哪里显示存在问题？
我已经考虑过其他一些解决方案，例如添加一些更新
标志。但它并不安全，因为当执行以下部分读取方法时，stl :: map可能会更新
。并且标志上的
操作也可能被其他
线程中断。
您需要某种同步，包括所有
读取。 （别忘了，std :: map返回对
内部数据的引用，只要这些
引用有效，就需要保持锁定。）
-
James Kanze（GABI软件）电子邮件：ja ********* @ gmail.com
Conseils eninformatiqueorientéeobjet/
Beratung in objektorientierter Datenverarbeitung
9placeSémard，78210 St.-Cyr-l''coco，France，+ 33（ 0）1 30 23 00 34
James Kanze写道：
9月13日凌晨3:18 ，Bill David< billdavi ... @ gmail.comwrote：
> SUBJECT：如何提高这个程序的效率？
>在我的程序中，一个线程会定期检查来自服务器的更新
并为其他部分生成一个stl :: map
程序从中读取数据。让我们将更新方法命名为
doUpdate，将stl :: map读取方法命名为getData和copyData。
由于stl :: map不是线程安全的，我们应该通过以下方式进行同步：我们自己。一个可用的解决方案是在上述所有方法中创建一个
boost :: mutex :: scoped_lock对象，以便对所有方法进行同步访问。但由于doUpdate
方法会定期执行且间隔可能是1小时或更长，而所有其他部分只能读取
stl :: map，上面的解决方案可能会同步太多了。
当我们进行doUpdating时，我们只需要对所有方法进行同步。
如果有任何线程修改对象，那么必须同步所有访问
。期。
这是不正确的。缓存是一个明显的反例，其中作者
可以写一个单词（一个指向更新的不可变缓存的指针）
原子地读者可以安全地原子地读取单词
完全锁定。
-
飞行青蛙咨询有限公司Jon D Harrop博士
http://www.ffconsultancy.com/?u
Bill David写道：
主题：如何提高这个程序的效率？
除非你指的是在C ++的范围内。最显着的改进
将使用不可变的地图，因为它们大大减少了所需的锁定
，甚至可以完全消除它。
-
飞行青蛙咨询有限公司Jon D Harrop博士
http://www.ffconsultancy.com/?u
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.
Then is it possible to make this program more efficient?
I have thought out some other solution like add some updating flag.
But it''s not safe since stl::map may be updated when the following
part of read methods is executing. And the operation on the flag may
also be interrupted by other threads.
On Sep 13, 3:18 am, Bill David <billdavi...@gmail.comwrote: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. 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.
Then is it possible to make this program more efficient?Probably. Where does the profiler show that there are problems?
I have thought out some other solution like add some updating
flag. But it''s not safe since stl::map may be updated when
the following part of read methods is executing. And the
operation on the flag may also be interrupted by other
threads.You need some sort of synchronization, including for all of the
reads. (Don''t forget, too, that std::map returns references to
internal data, and you need to hold the lock as long as these
references are valid.)
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l''école, France, +33 (0)1 30 23 00 34
James Kanze wrote:On Sep 13, 3:18 am, Bill David <billdavi...@gmail.comwrote:>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.That is incorrect. Caches are an obvious counter example where the writer
can write a single word (a pointer to the updated immutable cache)
atomically and readers can read the word atomically safely without any
locking at all.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Bill David wrote:SUBJECT: How to make this program more efficient?Unless you mean "within the confines of C++" the most obvious improvement
would be to use an immutable map because they greatly reduce the locking
required and can even completely eliminate it.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
这篇关于如何提高这个程序的效率？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
