Howard Hinnant writes:

...

It looks like you are locking your structure in "read mode" and then writing to it:

...

boost::shared_lockboost::shared_mutex lock(rwMutex); for(boost::unordered_set<int>::iterator it=tablePush[pair (type, code)].begin();it!=tablePush[pair(type, code)].end ();it++){ flag=true; des->push_back(*it); }

If you want to lock it in write mode do this:

boost::unique_lockboost::shared_mutex lock(rwMutex);

-Howard

Hi Howard, Did you mean des->push_back(*it) in this method? actually in my program, there is an independent fdList(which called "des" in the method) in every thread, in other words every thread have its own fdList and just reference into this method when they calls this method. In my opinion, if every fdList is declared independently in each thread, they won't take effect each other when they are referenced into this method and ask to push_back what this method found in the loop to them. did this also have to use write lock? I thought it's still read mode(If I'm incorrect please tell me) (this method push_backs what it found into every fdList every thread owned, they didn't push_backs in the same "global" fdList at the same time. This method just "read" the same tablePush without write it, that's why I think it's just in read mode..) Or did you mean the other place in my code is incorrect? Thank you Zap

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, March 16, 2011, Zap wrote:

I just tested a simple case, which just lock the read lock and print out the result of tablePush.size(), like this:

bool getFD(list<int> *des, char *type, char *code){ bool flag=false; boost::shared_lockboost::shared_mutex lock(rwMutex); cout<(type, code)].size()<

but it still happens Segmentation Fault...

could anyone know what's the problem is?

operator[] on maps can modify the map. Maybe you want to use find() instead? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk2AtF8ACgkQ5vihyNWuA4U8dwCgqo2WMSY9JLSbNL8x1je8Qd2Y XtEAoLkH9S0m9LE8nMH4idirsz2UsNi3 =TB03 -----END PGP SIGNATURE-----

On Thu, 17 Mar 2011 15:48:37 +0100, Zap wrote:

Frank Mori Hess writes:

...

operator[] on maps can modify the map. Maybe you want to use find() instead?

Hi Frank,

I'll try it later, thanks for your answer,

Is there any difference of performance between using operator[] and .find()?

Performance difference?!? Do you realize how much new/delete operations you trigger by constructing pair from two const char* literals and by simple assignment of two keys? To the matter of question - I would not expect any performance difference, especially if compiled with optimization, but I cannot speak for boost implementation.

especially in frequently finding key/value of pair in boost::unordered_map, boost::unordered_set<int> >.

and another question is, could I use container in container such as what I wrote(unordered_set as value in unorder_map)? is this kind of structur undefine-behaviour or it's acceptable?

if it's acceptable, did this kind of structure will cause decrasing of performance or won't?

You may use these constructs, but you must be very carefully not to trigger occasionally deep copy when not intended to.

if it will, what kind of instead structure could I use to satisfy what I need to do?

It all depends on your project and associated performance requirements. Variants include using indices instead of string pairs (think of atoms in xlib), I would definetely use pointers/smart_pointers as values in the map instead complex values itself or some kind of indices to other tables if pointers are not suitable. Btw the integer set, which you use as the map value, may be implemented much more effeciently as bitset if the range for your integers is small. // Have you noticed how gently have we drifted away from the topic theme ;) -- Slava