Re: [boost] Proposal for Lwsync library.

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.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