Le 04/06/2012 02:03, Andrew Wiley a écrit :
On Sun, Jun 3, 2012 at 4:39 PM, deadalnix <deadal...@gmail.com
<mailto:deadal...@gmail.com>> wrote:
Le 03/06/2012 21:40, Andrew Wiley a écrit :
On Sun, Jun 3, 2012 at 12:29 PM, deadalnix <deadal...@gmail.com
<mailto:deadal...@gmail.com>
<mailto:deadal...@gmail.com <mailto:deadal...@gmail.com>>> wrote:
Le 01/06/2012 22:55, Sean Kelly a écrit :
On Jun 1, 2012, at 5:26 AM, deadalnix wrote:
The main drawback is the same as opApply : return (and
break/continue but it is less relevant for
opSynchronized).
Solution to this problem have been proposed in the past
using compiler and stack magic.
It open door for stuff like :
ReadWriteLock rw;
synchronized(rw.read) {
}
synchronized(rw.write) {
}
Opens the door? This works today exactly as outlined
above. Or
am I missing a part of your argument?
And many types of lock : spin lock, interprocesses
locks,
semaphores, . . . And all can be used with the
synchronized
syntax, and without exposing locking and unlocking
primitives.
All works today.
Unless you do some monitor magic, it doesn't.
Yes, it does.
-----
class Something {
private:
ReadWriteLock _rw;
public:
this() {
_rw = new ReadWriteLock();
}
void doSomething() shared {
synchronized(_rw.read) {
// do things
}
}
}
-----
I've used this pattern in code. There might be some casting required
because the core synchronization primitives haven't been updated
to use
shared yet.
And where is that ReadWriteLock ?
On the GC heap, just like the Monitor object pointed to by __monitor if
you mark a method or class as synchronized.
I meant where is the code ?