Boost logo

Boost :

From: Vladimir Frolov (voidbent_at_[hidden])
Date: 2006-06-02 09:55:58

Sebastian Redl <sebastian.redl_at_[hidden]> 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 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:

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;
   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();
   // 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at