View mode: basic / threaded / horizontal-split · Log in · Help
July 14, 2011
Expose underlying Mutex in Condition?
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
July 14, 2011
Re: Expose underlying Mutex in Condition?
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 »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.

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

-STeve
July 19, 2011
Re: Expose underlying Mutex in Condition?
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.
Top | Discussion index | About this forum | D home