• David Nadlinger <see klickverbot.at> Jul 14 2011
• "Steven Schveighoffer" <schveiguy yahoo.com> Jul 14 2011
• Sean Kelly <sean invisibleduck.org> Jul 19 2011

David Nadlinger <see klickverbot.at> writes:

A quick idea I just had, feel free to shoot it down if I missed 
something obvious:

I have been writing some »old-school« multi-threading code lately, and 
it occurred to me that most of the time, I am using condition variables 
like this:

---
auto fooMutex = new Mutex;
auto fooCondition = new Condition(fooMutex);

[…]

// Later in the code:
synchronized (fooMutex) {
   […]
   fooCondition.notifyAll();
   // or
   fooCondition.wait();
}
---

When actually using the condition variable, I often don't care what the 
underlying mutex actually is, I just want to lock it so I can wait() on 
the condition variable or notify() it. Thus, it would be convenient if 
Condition had a »mutex« property exposing the underlying mutex, to avoid 
having to remember which Mutex belongs to which Condition.

What do you think of it? Did I miss something? The »issue« can easily be 
worked around by a suitable naming convention for the pairs of 
Mutexes/Conditions, but still I feel a Condition.mutex property would 
make typical code look cleaner.

David

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Thu, 14 Jul 2011 14:26:04 -0400, David Nadlinger <see klickverbot.at>=
  =

wrote:

 A quick idea I just had, feel free to shoot it down if I missed  =


 something obvious:

 I have been writing some =C2=BBold-school=C2=AB multi-threading code l=



 it occurred to me that most of the time, I am using condition variable=



 like this:

 ---
 auto fooMutex =3D new Mutex;
 auto fooCondition =3D new Condition(fooMutex);

 [=E2=80=A6]

 // Later in the code:
 synchronized (fooMutex) {
    [=E2=80=A6]
    fooCondition.notifyAll();
    // or
    fooCondition.wait();
 }
 ---

 When actually using the condition variable, I often don't care what th=



 underlying mutex actually is, I just want to lock it so I can wait() o=



 the condition variable or notify() it. Thus, it would be convenient if=



 Condition had a =C2=BBmutex=C2=AB property exposing the underlying mut=



 having to remember which Mutex belongs to which Condition.

 What do you think of it? Did I miss something? The =C2=BBissue=C2=AB c=



 worked around by a suitable naming convention for the pairs of  =


 Mutexes/Conditions, but still I feel a Condition.mutex property would =



 make typical code look cleaner.


Hm... actually, we could do away with the mutex, and have the condition'=
s  =

monitor be the mutex:

auto fooCondition =3D new Condition(); // automatically generates new mu=
tex.

synchronized(fooCondition)
{
    fooCondition.notifyAll();
    // or
    while(!someCondition)
      fooCondition.wait();
}

We could keep the current behavior (accept a mutex), but still have the =
 =

mutex passed in be used as the monitor for the condition.  Actually, can=
 a  =

mutex be used as the monitor for more than one object?  Because it's  =

possible multiple conditions can use the same mutex, so it's a legitimat=
e  =

concern.

Sean?  I think this is a really good idea...

-STeve

Sean Kelly <sean invisibleduck.org> writes:

Steven Schveighoffer Wrote:
 
 Hm... actually, we could do away with the mutex, and have the condition's  
 monitor be the mutex:
 
 auto fooCondition = new Condition(); // automatically generates new mutex.
 
 synchronized(fooCondition)
 {
     fooCondition.notifyAll();
     // or
     while(!someCondition)
       fooCondition.wait();
 }
 
 We could keep the current behavior (accept a mutex), but still have the  
 mutex passed in be used as the monitor for the condition.  Actually, can a  
 mutex be used as the monitor for more than one object?  Because it's  
 possible multiple conditions can use the same mutex, so it's a legitimate  
 concern.
 
 Sean?  I think this is a really good idea...


Seems easy enough.  Why not.