Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

how to lock only once method  RSS feed

 
Meir Yan
Ranch Hand
Posts: 599
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all
i have multithreaded problem on which i have method that multiple threads
are accessing this method is responsible on setting value this value needs to be set only once ( then it lives in all the application life time ).
how can i make sure that only the first thread that comes will set access this method and preventing race condition then when this value is set all other threads will not be synchronize in this method.
Thanks for helping
 
Angel Taveras
Ranch Hand
Posts: 84
Eclipse IDE Hibernate Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Meir Yan, you could use and Object Lock to lock your method once, something like this

class ClassWithMethodSyncOnce
{
private Object lock=new Object();

private volatile boolean sync;

public void methodToSyncOnce()
{
if(!sync)
{
synchronized(lock)
{
sync=true;
}
}
// the rest of the code goes here
}
}

This approach have a little drawback and it's, that a the thread could be executed, concurrency while setting the sync variable to true, but with no side effects. I don't know if an AtomicReference could help you better with this.
 
Ivan Koblik
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Meir Yan, in your case the Double-Checked Locking (DCL) may be of help.
At this page you will find more then enough on DCL.
Basically you need to do the next


[ December 02, 2008: Message edited by: Ivan Koblik ]
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ivan: I think volatile definitely is necessary there. Furthermore you need to set isDone = true only after theMethod() is called. Your implementation above would allow another thread to come in and see isDone == true before theMethod() has executed, which is a bug.

Also, note that implementing double-checked locking using volatile will only work if you're using JDK 5 or later.
 
Ivan Koblik
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike, doesn't Java reconcile all the variables with the main memory when entering synchronized block? Please see: Use synchronized or volatile.
On the second point you're right, flag should be set to true only after completion of theMethod(). Sorry about that.
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Ivan]: Mike, doesn't Java reconcile all the variables with the main memory when entering synchronized block?

Yes, it does - once when you enter the sync block, and once when you exit. However the JVM is permitted to reorder operations within the sync block, if it can prove to itself that doing so would not affect the results seen by a single thread executing a method. In this case, for a single thread,

is equivalent to

(assuming that theMethod() does not depend on isDone) so either order is OK as far as the JIT is concerned. The JIT might also do something like inline the call to theMethod() and then reorder actions within that method - then maybe isDone = true might be moved to be next to other statements that write to main memory, because that may be more efficient than several unrelated writes in different parts of the code. I don't know how likely that is, or exactly what sort of optimizations really occur in working code. But this sort of reordering is legal. So it's something you have to guard against if you're using multiple threads.

As an aside, this would not be an equivalent reordering:

Because here, the reordering would clearly affect even a single thread executing the code. That sort of thing is not allowed, as you'd expect. The problems occur when we have code where reordering would not affect a single thread, but could affect multiple threads. That's where unexpected things can happen, and placement of synchronized and volatile becomes critical.
 
Ivan Koblik
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike thanks for the insight, I didn't see the potential issue. I have reread the article that I gave a link to in my first post: The Limits of Code Optimization: a new Singleton Pattern Implementation.
So you can either use volatile variable or some oracle function that always returns true but cannot be optimized by java (please see the article, it should also pretend to use the results of theMethod()). This way you can have a working DCL in Java 1.4
 
Meir Yan
Ranch Hand
Posts: 599
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks allot guys for your help i did use what you said and its working great
now i have one more question and i dont know if i need to open new thread for that .
my question is :
im using in my application corba client that makes invocation to the server
and its responsible for opening threads now i think something wrong with this client and it opening less thread then i invoking for example
if i using 100 threads i see that in the server im getting only 4 threads
im afraid this client is queuing my threads and letting only 4 thread to be invoked , how can i make sure or how can i inspect this client to be sure whats going on ? its closed source .
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!