synchronized (this[.classinfo]) in druntime and phobos
deadalnix
deadalnix at gmail.com
Sun Jun 3 16:39:59 PDT 2012
Le 03/06/2012 21:40, Andrew Wiley a écrit :
> On Sun, Jun 3, 2012 at 12:29 PM, deadalnix <deadalnix at gmail.com
> <mailto:deadalnix at 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 ?
More information about the Digitalmars-d
mailing list