Sebastian Redl <sebastian.redl@getdesigned.at> wrote:
I think wait_for() should return a lock object on the monitor's resource. Otherwise, the vector could be emptied again before thread 1 gets to execute anything. (Only each individual access is locked in your system.) Generally, there should be a way to obtain a lock for a resource that outlasts a single call. If this is implemented as I guess it is, you might also suffer from the not clearly defined temporary destruction semantics.
Lwsync patterns provides accessors objects to access resource. One can read/change some resource only via its accessors. Both access() and wait_for() methods returns an accessors so that one cannot change resource until this accessor will be destryed. For example: { monitor_vector_t::accessor vector_access = monitor_vector.wait_for(is_not_empty); // monitor_vector cannot be changed until object vector_access is exists. for(size_t i = 0; i < vector_access->size(); ++i) *sync_cout.access() << "Index : " << i << ", Data : " << (*vector_access)[i] << std::endl; } To obtain the access to resource that outlasts a single call you have to use automaitc accessor objects (Like in my example 1). If you want to make a single call you can use temporary objects: monitor_vector.access()->push_back(10); You can even escalate access to critical resource from within scope of you own routine. Like this: monitor_vector_t::accessor some_vector_action() { monitor_vector_t::accessor vec_access = monitor_vector; vec_access->puch_back(10); return vec_access; // Access is escalated from within a some_vector_action() scope // So that one can make some other action with vector before it becomes // unlocked. } { monitor_vector_t::accessor vec_access = some_vector_action(); vec_access->puch_back(20); // There are guarantee that Elements 10 and 20 will be placed in // vector sequentially. // Any other action with vector cannot be processed between those two // push_back's. } Or use even dynamic objects to control lifetime of access manually. Unfortunatly I hear nothing about not clearly defined temporary destruction semantics problem. All compilers I am able to test (VC7.1, VC8.0) destroy temporary objects exacly after experession where it was created. Could you please refer me to description of this problem? --- With respect, Vladimir Frolov