digitalmars.D - Expose underlying Mutex in Condition?
- David Nadlinger (27/27) Jul 14 2011 A quick idea I just had, feel free to shoot it down if I missed
-
Steven Schveighoffer
(33/59)
Jul 14 2011
On Thu, 14 Jul 2011 14:26:04 -0400, David Nadlinger
... - Sean Kelly (2/23) Jul 19 2011 Seems easy enough. Why not.
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
Jul 14 2011
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=ately, and =it occurred to me that most of the time, I am using condition variable=s =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=e =underlying mutex actually is, I just want to lock it so I can wait() o=n =the condition variable or notify() it. Thus, it would be convenient if==Condition had a =C2=BBmutex=C2=AB property exposing the underlying mut=ex, to avoid =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=an 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 =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
Jul 14 2011
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.
Jul 19 2011