On 29-05-2012 01:41, Jonathan M Davis wrote:
On Tuesday, May 29, 2012 01:35:23 Alex Rønne Petersen wrote:
I don't think arguing about them makes sense at this point. Way too much
code would break if we changed the semantics. I'd consider it a mistake
and a lesson learned, rather.
But I take it you agree that synchronized (this) and similar
"uncontrollable" synchronization blocks should be avoided?
I'm not an expert on threading stuf, but it would be my opinion that if you're
not intending to protect the entire class with locks that it makes no sense to
lock on the class itself. You're locking for something specific, in which case,
your sychronized block should be locking on something else specific to what
you're trying to protect. Certainly, that's how I'd approach it with mutexes.
You don't have a mutex for an entire class unless it's actually used for all
of the class' functions. Rather, you use mutexes specific to what you're trying
to protect.
- Jonathan M Davis
Right, but even if you really *are* protecting the entire class, you can
still create mysterious deadlocks if users of your code lock on your
class. So I'm arguing that no matter the use case, never lock on a
'this' reference exposed outside of some API layer.
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
