Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
"I'm not back." - Bill Harding, Twister
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Originally posted by Jim Yingst:
[b]But I ran the code, and observed results similar to MM's. About 60% of the time, all three threads block on "waiting..." as expected. 35% of the time though, all three threads complete with "Got lock". Less than 5% of the time, one or two threads wait, while remaining threads complete. For what it's worth, I'm running J2SDK 1.4.2_03 on XP Pro.
Originally posted by David Weitzman:
Does anyone have any thoughts on what the javadocs should say about this?
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Originally posted by Michael Morris:
Does anyone have any thoughts on what the javadocs should say about this?
If we take action, do we go thru the formal process of filing a bug report which some Sun engineer may subjectively dismiss out of hand or try to get clarification from some other source? I've gone thru all the texts I have on Java threads and monitors and have found nothing that warns a developer not to lock on a Runnable. That indicates to me that very few in the industry are aware of this. But as David says good practice would preclude one from having a problem with this anyway.
Originally posted by David Weitzman:
It seems there are a few options for policy-type people.
2) Declare that this is a bug in the Thread implementation and modify it to use a private lock. There may be other classes in the foundation classes with similar bugs that need fixing. Class libraries not released by Sun may abide by their own policies.
3) Document this behavior in the Thread class and any other foundation classes that synchronize on or notify themselves (as well as any objects they return).
Realistically I think if I were Sun I'd go with option 1 but remove all instances of synchronized(this) in the codebase just for the sake of information hiding. It's good to get people in the habit of not making assumptions about undocumented behavior of other code.
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher