On 30-05-2012 19:12, Andrei Alexandrescu wrote:
On 5/30/12 9:23 AM, Alex Rønne Petersen wrote:
On 30-05-2012 18:14, Andrei Alexandrescu wrote:
This is news to me. How do you publicly access the mutex of a
synchronized class object?
Generally in two ways:
1) synchronized (obj)
This is not accessing the mutex for arbitrary operations.
No, it is indeed not. You didn't explicitly say you wanted to do
"arbitrary operations", so I assumed that by accessing the mutex you
meant doing the only two things that are sensible for a mutex: Locking
and unlocking it. What else would you want to do? This discussion has
always been about locking and unlocking publicly exposed mutexes. I
don't think arguing about "arbitrary operations" is going to get the
discussion anywhere exactly because of what you proceed to say ...
2) obj.__monitor
All symbols starting with two underscores are reserved by the
implementation.
... since that effectively means there is no way, from an
implementation-independent standpoint, to alter the memory of a mutex
(or whatever) (see my answer below), thus making the only sensible
operations on a mutex locking and unlocking.
But I may be misunderstanding you. If so, please clarify and/or correct me.
(Just so we're clear, I included (2) only for completeness. I know it's
a dirty hack and I agree that it should never be in the language 'spec'
or TDPL.)
(1) accesses it in order to actually do locking, but if obj is an
instantiation of a class that uses the this reference internally for
locking, you end up with potential deadlocks.
Deadlocks are endemic to mutex-based programming and are not avoided
inherently or preferentially by the alternative you discussed (exposing
unrestricted mutex).
Therefore, you can say
that obj's mutex is exposed.
Nothing could stop one, but that claim is incorrect.
It is exposed as far as using it for anything sensible goes. No,
synchronized (obj) does not let you delete the monitor of obj or alter
it or something along these lines, but I don't think that's worth
bringing into this argument. This has always been about locking and
unlocking a publicly exposed mutex, and about preventing common deadlock
sources.
Andrei
--
Alex Rønne Petersen
[email protected]
http://lycus.org
