views:

349

answers:

4

Is there a way in Java to get a method to lock (mutex) the object which it is in?

I know this sounds confusing but basically I wan't an equivelent to this snippet of C# but in Java.

lock(this)
{
    // Some code here...
}

I've been tasked with reimplementing an API written in .Net into Java, and I've been asked to keep the Java version as similar to the .Net version as humanly possible. This isn't helped by the fact that the .Net version looked like it was transcribed from a C++ version which I don't have access to.

Anyway the above line appears in the C# version and I need something that does the same in Java.

+6  A: 

The equivalent of that is:

synchronized (this)
{
}

(And no, you shouldn't generally do it in either C# or Java. Prefer locking on private references which nothing else has access to. You may be aware of that already, of course - but I didn't want to leave an answer without the warning :)

Jon Skeet
Thanks Jon, I was convinced I'd tried that and Eclipse was moaning about it. Maybe I'd mis-spelt synchronised and hadn't noticed.
Omar Kooheji
Why should you prefer to lock private references? See also http://stackoverflow.com/questions/416183/in-java-critical-sections-what-should-i-synchronize-on#416198
eljenso
Because then other code can't expectedly lock on you. It's like exposing more methods than you have to - but harder to debug, because threading is fundamentally hard.
Jon Skeet
See item 70 in the second edition of Effective Java for more details - and also how to lock when you *do* have to use public references as part of the API.
Jon Skeet
I've read the item and I still feel that "you shouldn't generally do it" is overstated (esp. considering the scope of the question). I would say: it is something typical to do. "Threading is fundamentally hard" is something you can throw at almost anything, but no one will be any wiser.
eljenso
eljenso: I think we'll have to agree to disagree. The fact that threading is hard makes it all the more important to be as careful as you can - and making it impossible for other code to accidentally lock on the same thing you're locking on count as being careful IMO. (continued)
Jon Skeet
If you *want* to expose the lock, then that's one thing - but otherwise, what benefit is there in locking on something which others might lock on? There's the tiny, tiny benefit of not having to create a new object - but that's basically it. See also P636-639 of Jeff Richter's CLR via C#.
Jon Skeet
(I'll check whether Joe Duffy's latest book has a similar entry when I get back tonight. I thought it was pretty much understood and accepted guidance these days, in the same manner as not exposing fields publicly...)
Jon Skeet
I don't mind being wrong on this one, I will actually learn something from it. I just need good examples (no foo-bar stuff). I definitely want to know more, maybe a new question is needed here? I'm at "work" right now (yeah right) so I'll have to continue this later as well.
eljenso
Yup, a new question could raise some interesting discussion. It's not so much a "right or wrong" question as "defensive practices". As with a lot of best practices, it's more important for class library design (where you don't know the consumer) than straight app development.
Jon Skeet
Great answer, but I do think that "threading is fundamentally hard" is unhelpful (although perhaps true). It too easily becomes an excuse for programmers not to learn threading properly.
Draemon
I think the context is important here - I was using "threading is fundamentally hard" as a reason to pay even more attention to best practices and defensive coding when it comes to threading than elsewhere. Apologies if that wasn't clear.
Jon Skeet
Continued at http://stackoverflow.com/questions/442564/avoid-synchronizedthis-in-java
eljenso
+5  A: 

Assuming that the C++ code is a simple mutex, replace "lock" with "synchronized"

synchronized (this)
{
// ...
}

Here's the Java Concurrency tutorial for more info

kdgregory
A: 

I'd recommend Brian Goetz's "Java Concurrency In Practice." It's an excellent book.

It can be a good thing to keep the synchronized block as small as possible. Using the synchronized modifier on the method is coarse-grained and sometimes necessary, but otherwise you can use another object to do it that keeps the block smaller.

Like this:

public class PrivateLock {
    private final Object myLock = new Object();
    @GuardedBy("myLock") Widget widget;

    void someMethod() {
        synchronized (myLock) {
            // Access or modify the state of widget
        }
    }
}
duffymo
+1  A: 

You should also look into the java.util.concurrent package of the API (JDK 5.0+) for additional concurrency management objects such as semaphore, exchanger, etc

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/package-summary.html