Interview question

[Tejas Chachcha]

A scenario is like...

I have a thread class T which has a synchronized method say printit() which does something on a printer.

Now question is what would happen if there are two threads executing method printit()? What if both threads are executing in different JVMs? Would it still be synchronized access to the printer?

Tejas

[Ernest Friedman-Hill]

Synchronization has no effect across different JVMs, and, actually, as described, your synchronized method has no worthwhile effect ever. You said that printit() is a member of a Thread subclass, so presumably it will be used by the Thread object in which it appears. If each Thread calls printit() on its own Thread instance, then the synchronization will have no effect; synchronization only does something if two threads try to call a synchronized method on the same object.

[Tejas Chachcha]

Assume that the printit method is synchronized on some common object of a class implementing runnable inteface...

As you said...

Synchronization has no effect across different JVMs

It cleared my doubt...

Is there any solution to this scenario? If we want to make access from different jvms synchronized? Does it mean that synchronization/threading can make java somewhat plateform independent?

[Ernest Friedman-Hill]

If multiple processes -- Java or otherwise -- need to synchronize access to a resource, then generally what you need to do is make one process the owner of that resource, and force other processes to ask the owner for access; i.e., in your case, a print server which manages a printer queue.

I don't understand the question about platform (in)dependence.

[Andrew Trumper]

Originally posted by Tejas Chachcha:

Is there any solution to this scenario? If we want to make access from different jvms synchronized? Does it mean that synchronization/threading can make java somewhat plateform independent?

There's a few ways. One way is to have a process "own" that resource. Another is to make use of the file system's atomicity and java.io.File's createNewFile() method to create files on a file system that represent resources you want to lock. This second method is usally used despite the fact you have to watch out for a bunch of things like the app dying without releasing the lock... (This is usually fixed by some sort of keep-alive time stamp thing).

See ->
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4676183
.. why making use of deletion on exit doesn't always work

I've used both app based system wide locks and file based system wide locks in past projects with great success...