I just came back from an interview from which I took away an interesting nugget of knowledge. The interviewer asked me the following:
"There is a class Foo. It has a public synchronized method A and public method B (unsynchronized). If a thread is currently executing method A, is any other thread allowed to execute method B?"
My answer was "yes, any number of threads can execute an unsynchronized method". Regardless of the current status of the method A. To my surprise the answer was deemed incorrect.
He referred to some feature of the JVM which (allegedly) automatically bans all other threads from accessing any (sync-ed or not) method of an object, if any synchronized method of the object is currently being executed by a thread.
News to me...I couldn't find any references to such feature. And if it did exist, it wouldn't make any sense to me. Please post your opinion, I need to resolve this for myself one way or another.
I must admit I'm not a concurrency expert but I can't see what the synchronized should be really good for and how it should work in practice if one synchronized method would block all other methods of a class I can't imagine what kind of feature your interviewer was talking about but synchronized methods can only be executed by a thread if the (intrinsic) lock of an object can be acquired by the thread. Unsynchronized methods can be executed by any thread. That's it.
Of course there are other things to synchronize multiple threads besides the "synchronized" keyword and it may depend on details what exactly a method is doing internally but I think your interviewer was wrong if he was talking about the simple scenario you described.
Perhaps I should have mentioned that I'm not 100% sure :-) So any other comments are welcome but I would really be surprised to hear of such a JVM feature...
It sounds as though the interviewer is simply wrong. A public unsynchronized method can be called by any thread at any time, regardless of what's going on with synchronized methods. If you still want the job, you could write a polite e-mail containing sample code that clearly shows two different threads executing different methods on the same object at the same time, where one method is synchronized but the other isn't.
Puh, good to hear that the interviewer was obviously just wrong
@Alex: The question is now if how you really want a job in this company. In my opinion it's absurd to discuss such low level details in an interview (unless the company is really looking for an absolute expert in concurrent programming). And it's even worse to tell you that YOU are wrong if the interviewer himself has no idea of this topic. If I had to do such interviews (as an interviewer) I'd never ask any question of which I'm not definitely sure I know the correct answer. In any case I'd do what Mike proposed and let him at least (politely) know that he was NOT right!
Marco Ehrentreich wrote:
@Alex: The question is now if how you really want a job in this company.
Spot on, Marco! lol
thanks everyone, I guess this concludes the technical part of this discussion. Unless the person in question stumbles upon this post and clarifies any possible misunderstanding on my part.
Marco Ehrentreich wrote:In my opinion it's absurd to discuss such low level details in an interview (unless the company is really looking for an absolute expert in concurrent programming).
Hurm. This doesn't strike me as an expert question - more like low-intermediate for thread programming - admittedly a difficult topic. But this is pretty fundamental to what the synchronized keyword actually means, for anyone who considers themselves qualified to use it at all. Which of course makes it all the more appalling that the interviewer insisted on the wrong answer. Aside from that, though, I think the question is fair game under either of the following conditions:
(a) the company has a real need for programmers who really understand concurrent programming (and based on the interviewer's lack of skill, this seems quite plausible)
(b) the candidate has indicated, on their resume or in conversation, that concurrent programming is something they have significant experience in, or which is one of their strengths. In this case, it's not at all unreasonable for an interviewer to ask deeper questions, just in order to evaluate how truthful the candidate is being. Of course, this works best if the interviewer also has some clue as to what they're talking about.
Marco Ehrentreich wrote:And it's even worse to tell you that YOU are wrong if the interviewer himself has no idea of this topic.