On Mar 13, 2014, at 4:21 AM, Paul Sandoz wrote:
> On Mar 12, 2014, at 10:23 PM, John Rose wrote:
>> P.S. FTR, I wish we could also remove the per-object monitor from its
>> privileged position, so not all objects are burdened by it, and other forms
>> of lock can be switched into the existing
On Mar 12, 2014, at 10:23 PM, John Rose wrote:
> P.S. FTR, I wish we could also remove the per-object monitor from its
> privileged position, so not all objects are burdened by it, and other forms
> of lock can be switched into the existing notation on a type-by-type basis.
> This is obviously
P.S. FTR, I wish we could also remove the per-object monitor from its
privileged position, so not all objects are burdened by it, and other forms of
lock can be switched into the existing notation on a type-by-type basis. This
is obviously a long, long term wish. A starting point is a notion of
I think that we've covered all the angles, and that we can remove it.
– John
> On Mar 12, 2014, at 1:44 PM, Paul Sandoz wrote:
>
>
> Currently i cannot find any external uses of it.
On Mar 5, 2014, at 3:04 PM, Doug Lea wrote:
> A few comments on catching up with this discussion...
>
Same here, back from a holiday last week.
tryMonitorEnter() does no harm and it is out of reach of most
programmers.
>
> Built-in monitors are heavily optimized for "typical" cases,
On Feb 28, 2014, at 10:11 PM, John Rose wrote:
> On Feb 28, 2014, at 1:38 AM, Paul Sandoz wrote:
>
>>> But chances are, the day after I take it off, I will need it.
>>>
>>> tryMonitorEnter() does no harm and it is out of reach of most programmers.
>>>
>>
>> I think your analogy to a spare whe
On 03/06/2014 08:48 AM, Tom Hawtin wrote:
On 04/03/2014 15:32, David M. Lloyd wrote:
On 03/03/2014 09:45 PM, David Holmes wrote:
We should not introduce anything that allows something that was
guaranteed to be safe by the language, to become unsafe.
Define 'safe'. Because I don't think it'
On 04/03/2014 15:32, David M. Lloyd wrote:
On 03/03/2014 09:45 PM, David Holmes wrote:
We should not introduce anything that allows something that was
guaranteed to be safe by the language, to become unsafe.
Define 'safe'. Because I don't think it's unsafe, any more than
I believe even in
A few comments on catching up with this discussion...
tryMonitorEnter() does no harm and it is out of reach of most
programmers.
Built-in monitors are heavily optimized for "typical" cases,
which does not include any form of tryLock. So the hotspot
implementation of tryMonitorEnter is very slo
On Mar 4, 2014, at 7:41 PM, David Holmes wrote:
> I agree it is as unsafe as using Lock. I think not being able to forget to
> unlock a monitor is more than just convenient. YMMV and obviously does.
That's why that "unsafe" kind of stuff currently lives in class "unsafe".
Next there are safe w
On 5/03/2014 1:32 AM, David M. Lloyd wrote:
On 03/03/2014 09:45 PM, David Holmes wrote:
On 3/03/2014 10:56 PM, David M. Lloyd wrote:
Yes, that would necessarily be the contract of a Monitors class, just as
it is part of the contract of Lock today. If your argument is that it
shouldn't be allow
On 03/03/2014 09:45 PM, David Holmes wrote:
On 3/03/2014 10:56 PM, David M. Lloyd wrote:
Yes, that would necessarily be the contract of a Monitors class, just as
it is part of the contract of Lock today. If your argument is that it
shouldn't be allowed because it might be used wrong, we might a
On 03/04/2014 08:01 AM, Peter Levart wrote:
On 03/04/2014 05:09 AM, David Holmes wrote:
On 4/03/2014 1:45 PM, David Holmes wrote:
On 3/03/2014 10:56 PM, David M. Lloyd wrote:
Yes, that would necessarily be the contract of a Monitors class,
just as
it is part of the contract of Lock today. If
On 03/04/2014 05:09 AM, David Holmes wrote:
On 4/03/2014 1:45 PM, David Holmes wrote:
On 3/03/2014 10:56 PM, David M. Lloyd wrote:
Yes, that would necessarily be the contract of a Monitors class,
just as
it is part of the contract of Lock today. If your argument is that it
shouldn't be allowe
On 04/03/2014, David Holmes wrote:
> On 3/03/2014 10:56 PM, David M. Lloyd wrote:
>> Yes, that would necessarily be the contract of a Monitors class, just as
>> it is part of the contract of Lock today. If your argument is that it
>> shouldn't be allowed because it might be used wrong, we might a
On 4/03/2014 1:45 PM, David Holmes wrote:
On 3/03/2014 10:56 PM, David M. Lloyd wrote:
Yes, that would necessarily be the contract of a Monitors class, just as
it is part of the contract of Lock today. If your argument is that it
shouldn't be allowed because it might be used wrong, we might as
On 3/03/2014 10:57 PM, David M. Lloyd wrote:
On 02/27/2014 06:38 AM, David Holmes wrote:
On 27/02/2014 9:12 PM, Stephen Colebourne wrote:
On 26 February 2014 20:54, Martin Buchholz wrote:
It does seem that being able to tell whether a java object monitor is
currently locked is useful for debu
On 3/03/2014 10:56 PM, David M. Lloyd wrote:
Yes, that would necessarily be the contract of a Monitors class, just as
it is part of the contract of Lock today. If your argument is that it
shouldn't be allowed because it might be used wrong, we might as well
just delete most of the JDK, Reentrant
On 02/27/2014 06:38 AM, David Holmes wrote:
On 27/02/2014 9:12 PM, Stephen Colebourne wrote:
On 26 February 2014 20:54, Martin Buchholz wrote:
It does seem that being able to tell whether a java object monitor is
currently locked is useful for debugging and monitoring - there
should be a
way t
Yes, that would necessarily be the contract of a Monitors class, just as
it is part of the contract of Lock today. If your argument is that it
shouldn't be allowed because it might be used wrong, we might as well
just delete most of the JDK, ReentrantLock included, since it suffers
from the ex
On 27/02/2014 11:56 PM, Vitaly Davidovich wrote:
Right, there's no such guarantee/requirement. JVMS mentions that
implementations are permitted to enforce balance (called structured locking
there) but not required:
http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.html#jvms-2.11.10
And
Making the language Kindergarten-friendly at the cost of general
usefulness is a mistake, IMO. And anyway there's nothing that is less
safe about a Monitors class than ReentrantLock; on the other hand,
monitors continue to be considerably lighter (size and (for most of the
history of JUC) spee
With a curious 9 months old crawling around the house, I've just moved
the sharp knives to the top draw in the kitchen - out of reach. I don't
think we should be encouraging people to use monitor.tryLock() for
various reasons:
1. We have a richer interface with Lock/ReentrantLock, including b
Except that Lock has features that are not supported by intrinsic locks
(timed wait, interruptible wait.) So the Lock returned would not
conform to Lock's contract, and attempting to call these methods would
probably throw UOE.
On 2/27/2014 6:12 AM, Stephen Colebourne wrote:
On 26 February 2
On Feb 28, 2014, at 1:38 AM, Paul Sandoz wrote:
>> But chances are, the day after I take it off, I will need it.
>>
>> tryMonitorEnter() does no harm and it is out of reach of most programmers.
>>
>
> I think your analogy to a spare wheel is misleading. Continuing with the car
> theme i liken
On Feb 27, 2014, at 3:51 PM, Dr Heinz M. Kabutz
wrote:
> I have never used this "in the wild", but rather have moved over to the
> ReentrantLock when I needed that particular functionality.
>
> However, I do see a place for this ability. As I wrote in here:
> http://www.javaspecialists.eu/arc
On 2/27/14 4:29 AM, Paul Sandoz wrote:
This will allocate about 10 Thread objects per second until the other thread
finally reaches the synchronized read() method in BufferedInputStream...
>
I like it.
I like it too.
I do have a slight preference for Mandy's solution, see below, but i am not
On 02/27/2014 11:36 AM, Paul Sandoz wrote:
Hi David,
On Feb 27, 2014, at 3:24 PM, David M. Lloyd wrote:
(I'm the guy that wrote JBoss Modules, i.e. apparently the one usage "in the
wild" of these methods).
Yes :-) the only one i have found so far.
IIUC JBoss Modules only needs to use th
Plus, monitors can get optimized beautifully when there is no
contention, although that falls away for the code that uses
monitorEnter/monitorExit calls directly as far as I could tell.
Regards
Heinz
--
Dr Heinz M. Kabutz (PhD CompSci)
Author of "The Java(tm) Specialists' Newsletter"
Oracle Ja
Hi David,
On Feb 27, 2014, at 3:24 PM, David M. Lloyd wrote:
> (I'm the guy that wrote JBoss Modules, i.e. apparently the one usage "in the
> wild" of these methods).
>
Yes :-) the only one i have found so far.
IIUC JBoss Modules only needs to use those methods on Java 1.6, is that correct?
A "Monitors" class could possibly be introduced which simply has three
(intrinsic) static methods: void lock(Object obj), void unlock(Object
obj), boolean tryLock(Object obj).
Could even add a void lockInterruptibly(Object obj) throws
InterruptedException.
Why not? Monitors are not going an
I have never used this "in the wild", but rather have moved over to the
ReentrantLock when I needed that particular functionality.
However, I do see a place for this ability. As I wrote in here:
http://www.javaspecialists.eu/archive/Issue194.html - sometimes you need
to modify code that is al
This is actually a somewhat unfortunate "feature". Had this not been in
place, I could have just used custom bytecodes to perform the lock magic
that I ended up using Unsafe for (I'm the guy that wrote JBoss Modules,
i.e. apparently the one usage "in the wild" of these methods).
The restricti
Right, there's no such guarantee/requirement. JVMS mentions that
implementations are permitted to enforce balance (called structured locking
there) but not required:
http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.html#jvms-2.11.10
Thanks
Sent from my phone
On Feb 27, 2014 8:40 AM, "Jer
David Holmes wrote:
> I don't think this is workable. Exposing a monitor as Lock would allow
> you to break the guarantees/requirements involving balanced-locking for
> monitors.
Where are these guarantees/requirements documented?
Regards,
Jeroen
On 27/02/2014 9:12 PM, Stephen Colebourne wrote:
On 26 February 2014 20:54, Martin Buchholz wrote:
It does seem that being able to tell whether a java object monitor is
currently locked is useful for debugging and monitoring - there should be a
way to do that.
Perhaps it would be useful to be
On Feb 27, 2014, at 12:52 PM, Peter Levart wrote:
>
> Ok, then what about the following:
>
>static boolean isLocked(final Object monitor, final long millis) throws
> InterruptedException {
>return new Thread() {
>volatile boolean unlocked;
>
>@Override
>
On 02/27/2014 10:58 AM, David Holmes wrote:
On 27/02/2014 6:38 PM, Peter Levart wrote:
On 02/27/2014 08:41 AM, David Holmes wrote:
On 27/02/2014 5:30 PM, Peter Levart wrote:
On 02/27/2014 08:29 AM, Peter Levart wrote:
On 02/26/2014 09:54 PM, Martin Buchholz wrote:
I don't recall having added
On 26 February 2014 20:54, Martin Buchholz wrote:
> It does seem that being able to tell whether a java object monitor is
> currently locked is useful for debugging and monitoring - there should be a
> way to do that.
Perhaps it would be useful to be able to expose a java object monitor
as an ins
On Feb 26, 2014, at 7:10 PM, Brian Goetz wrote:
> Seems like a symbolic victory, at least :)
I'll take what ever small victory i can with this beast of a class :-)
> It's less unsafe than some unsafe methods (you can use it to create a DoS but
> not to violate safety constraints like bound
On 27/02/2014 6:38 PM, Peter Levart wrote:
On 02/27/2014 08:41 AM, David Holmes wrote:
On 27/02/2014 5:30 PM, Peter Levart wrote:
On 02/27/2014 08:29 AM, Peter Levart wrote:
On 02/26/2014 09:54 PM, Martin Buchholz wrote:
I don't recall having added this particular wart
to test/java/lang/Proce
On 02/27/2014 08:41 AM, David Holmes wrote:
On 27/02/2014 5:30 PM, Peter Levart wrote:
On 02/27/2014 08:29 AM, Peter Levart wrote:
On 02/26/2014 09:54 PM, Martin Buchholz wrote:
I don't recall having added this particular wart
to test/java/lang/ProcessBuilder/Basic.java, and history suggests t
On 27/02/2014 5:30 PM, Peter Levart wrote:
On 02/27/2014 08:29 AM, Peter Levart wrote:
On 02/26/2014 09:54 PM, Martin Buchholz wrote:
I don't recall having added this particular wart
to test/java/lang/ProcessBuilder/Basic.java, and history suggests that
others did that.
It does seem that being
On 02/27/2014 08:29 AM, Peter Levart wrote:
On 02/26/2014 09:54 PM, Martin Buchholz wrote:
I don't recall having added this particular wart
to test/java/lang/ProcessBuilder/Basic.java, and history suggests that
others did that.
It does seem that being able to tell whether a java object monitor
On 02/26/2014 09:54 PM, Martin Buchholz wrote:
I don't recall having added this particular wart
to test/java/lang/ProcessBuilder/Basic.java, and history suggests that
others did that.
It does seem that being able to tell whether a java object monitor is
currently locked is useful for debugging a
On 2/26/2014 12:54 PM, Martin Buchholz wrote:
I don't recall having added this particular wart
to test/java/lang/ProcessBuilder/Basic.java, and history suggests that
others did that.
It does seem that being able to tell whether a java object monitor is
currently locked is useful for debugging a
Seems like a symbolic victory, at least :) It's less unsafe than some
unsafe methods (you can use it to create a DoS but not to violate safety
constraints like bounds checking or pointer casting) but its a start!
On 2/26/2014 10:12 AM, Paul Sandoz wrote:
Hi,
Out of all the methods on Unsafe
Hi,
Out of all the methods on Unsafe i think the
monitorEnter/monitorExit/tryMonitorEnter are the least used and are very strong
candidates for removal.
99% of use-cases are supported by classes in the java.util.concurrent.locks
package.
Within the JDK itself it is only used in one JDK test
48 matches
Mail list logo
