I have a java multithreading issue. I have 2 threads accessing a methodA() which has a for loop inside and in the loop calls a methodB(). The method A should be locked using a thread-name lock and the method B should be locked on the object id that the method B operates on. Check the below code.
Currrent code
private static final ConcurrentHashMap<Object, Object> LOCKS = new ConcurrentHashMap<Object, Object>();
private void methodA(){
LOCKS.putIfAbsent(Thread.currentThread().getName(), new Object()))
synchronized (LOCKS.putIfAbsent(Thread.currentThread().getName(), new Object())) {
for(loop through all objects) {
methodB(Object1);
}
}
}
private void methodB(Object1 object1) {
LOCKS.putIfAbsent(object1.getObjectId(), new Object()))
synchronized(LOCKS.putIfAbsent(object1.getObjectId(), new Object())){
//<Work on object1>
}
}
I had done the above code to ensure that 2 different threads should be able to paralleley access methodA(), but should not work on same Object1 at a time in methodB() (which is invoked by methodA()).
ie; Though I want Thread A and Thread B to access methodA() at the same time, which in turn will loop through all objects in 'for' loop and will operate on each by calling methodB(), I dont want thread A and B to act on the SAME object instance at a time. Hence the above code to lock methodB() based on object instance ID.
The improvement needed.
In the above code if Thread A and Thread B comes to methodB() and finds that they both want to work over the same object 'obj1', right now with the above code either Thread A will wait or Thread B will wait for the other one to finish depending on who reached and locked methodB() first.
But imagine a case, where Thread A getting the lock first and executing methodB() takes 9 hours to finish processing 'obj1'. Thread B in this case will need to wait for the entire 9 hours before getting a chance to execute methodB() and thereby processing 'obj1'.
I don't want this to happen. Thread B, once it finds that methodB() is locked in the name of 'obj1' by Thread A should move on (and come back to obj1 later) to try locking and processing other objects. ie; it should try processing other objects in the 'for' loop like obj1, obj2 etc in the list of objects.
Any inputs to solve this 'lock without wait' problem will be appreciated.
Many thanks in advance for any help.
Some clarifications to improve the answers.
Both methodA() and methodB() is in same class. The methodB() is not in the Object class.
Actually Thread A and Thread B are timer threads that calls many methods including A and B. Hence the thread level lock (because thread gets called every 15 mins or so and there is a chance that the first execution of methodA() wont be completed before a second call to it).
methodB(Obj1) always takes a Object1 param and must be locked on it. The reason is, in this class there are be other methods say methodC(Obj1) and methodD(Obj1) that also takes in an Object1 param. These methods should not get executed at the same time for same instance of Object1. Hence the lock on Object1 param needed.
The Thread B finding that methodB(Obj1 obj) is already locked by Thread A() on obj1 needs to somehow call methodB() again but with a different object, say obj2. It should come back to obj1 once it finishes with the others.
The best thing you can do is to keep things simple.
The method A should be locked using a thread-name lock
Only locking shared objects makes sense. Lock a thread local lock is pointless.
synchronized(LOCKS.putIfAbsent(object1.getObjectId(), new Object()))
That will return null and throw a NullPointerException the first time it is run.
I would replace the code with
private void methodA(){
List<Object1> objects = new ArrayList<>(this.objectList);
while(true) {
for(Iterator<Object1> iter = objects.iterator() : objects)
if(object1.methodB())
iter.remove();
if(objects.isEmpty()) break;
Thread.sleep(WAIT_TIME_BEFORE_TRYING_AGAIN);
}
}
// in class for Object1
final Lock lock = new ReentrantLock();
public boolean methodB() {
if (!lock.tryLock())
return false;
try {
// work on this
return true;
} finally {
lock.unlock();
}
}
Depending on how you want to handle object which cannot be locked, you could add them to a background ExecutorService. You could have methodA repeatedly call all the remaining objects for which this fails.
Ideally you would find a way to minimise the time locked or even remove the need for a lock entirely. e.g. Classes like AtomicReference and CopyOnWriteArrayList are thread safe and lockless.
I am not a Java guy, but in my opinion you will not achieve this with synchronized. I believe you will need to do your own locking.
If you create a java.util.concurrent.locks.ReentrantLock you can use tryLock to enter the lock if it is not yet locked. methodA needs to know which methodB call was successful or which was canceled because the lock was not possible. So you could do the lock handling in methodA, giving you full control there. Or you could do the locking in methodB, but then you need some return value or exception handling to signal back to methodA if methodB did its work or if it did not get the lock.
Of course you will also need to keep a list in methodA of the objects you already went through or of the objects you still need to work on.
Does it matter if one thread pass occasionally 'misses' an object on a pass-through? If not:
Store all the objects in a lockable queue-style container. Have threads A, B etc. pop one out, call methods on it and then push it back in. It is then not possible for the threads to operate on the same object at the same time. The only lock is then on the container push/pop and no thread needs to block for any extended time.
..or something like that. I always try to avoid complex locking schemes - they always seem to screw up :(
I suggest a different approach. Instead of directly invoking the method, put a command object in a queue and have a thread (or an executor) process the commands.
When a command appears in the queue, try to get the lock. If that doesn't work, add the command to the end of the queue. This will make sure the command is tried again eventually.
Drawback: A command could be postponed indefinitely if some thread happens to have lock on it every time it's tried for execution.
The solution here would be to make sure you only lock what you need. That way, when you see "oh, this is locked", you know that someone is already working on the task and you can simply forget about the command (-> don't do work twice).
Related
I need to make sure I understand synchronization mechanism in java, here are couple scenarios Id like to ask about:
theres a list 'a':
List a
and there are two functions:
void foo(int i){
synchronized(a){
a.add(i);
}
}
int goo(){
return a.size();
}
If there are multiple threads running, and one of them uses synchronized code block in foo, can other threads at this time access goo (or more specifically, access 'a'?)? How about the opposite, if there is a thread accessing a at the momen through goo (which is unsynchronized), can a thread enter the synchronized block of foo? or is it going to wait on it?
Let there be:
void synchronized foo(){
// do stuff
notifyAll();
//do stuff
if(someStatement)
return;
wait();
//do stuff
}
Some thread enters foo and reaches wait block, it releases the key of 'this', right? Second thread enters foo, and reaches notifyAll, at this point the first thread who was waiting should wake up and continue the code of foo, but it doesnt make sense because the other thread is currently holding the key. So what will happen?
Let there be:
class A implements Runnable {
Thread b;
foo(){
b= new Thread(()-> { /*some lambda function*/};
b.start();
}
goo(){
//here I'd like to notify the thread of b, how do I do it?
}
}
What should I do if I want to notify a thread that I created with lambda function? this means I dont have a reference to it, but I do have a reference to object 'b'.
Thanks in advance.
This is me trying to learn java synchronization
If there are multiple threads running, and one of them uses synchronized code block in foo, can other threads at this time access goo (or more specifically, access 'a'?)? How about the opposite, if there is a thread accessing a at the momen through goo (which is unsynchronized), can a thread enter the synchronized block of foo? or is it going to wait on it?
Yes, multiple threads can access those methods at the same time currently, either way round.
However, this is not correct code: you need to synchronize access to a.size() on a in order to ensure that you see any updates to the data structure that occurred in goo. For example, foo might see a size of 0 even after you have added something into the list using foo.
So, you need to make the code such that two threads can't be in those blocks at the same time.
Please skip to the TLTR if you do not want to read the whole story but the question:)
I need to fix a bug in our system and I have found the bug but could not find an optimal solution for this problem.
As an illustration, what it is aimed to be done is; when there are three files to be closed and for each file, a different thread (3 threads in this example) is created and should get the id of the file and by using file's id, it should close the file.
However, the person, who programs this, did not think something genuinely. At the moment, three threads are created for three different files and they access to the method, which distributes the ids, at the same time and the method gives the id of the first file (normally, first id to first thread, second id to second thread and third id to the third thread should be given) to three threads and these three threads try to close the same file (which causes the bug).
I cannot change this structure and it should be remain as it is.
TLTR
What I try to achieve is; how can I prevent several threads from entering the same method at the same time?
I tried synchronized (and lock) strategies for this but they did not help me in this situation, because each thread has its own lock (there are several objects created).
Create a singleton.
public static final Object globalLock = new Object();
Then in your methods where you need to protect.
synchronized(globalLock){
//get your file ids.
}
Couple of ways for doing this, here are some:
Make method synchronized
public class MyClass{
public void synchronized mySynchronizedMethod(); // only single thread will be allowed to invoke this method on the SAME INSTANCE OF MyClass
public void notSynchronizedMethod();
}
Use synchronized block:
MyClass obj=new MyClass();
synchronized(obj){
// only single thread is allowed to enter that block WITH obj INSTANCE.
obj.notSynchronizedMethod():
}
Synchronize on class
MyClass obj=new MyClass();
synchronized(MyClass.class){
//single thread is allowed for this block in a scope of WHOLE CLASS LOADER so in most cases you can say it is "globally" synchronized
}
Use Semaphore
Semaphore sem=new Sempahore(1);
sem.aquire(); // Thread will aquire permit, another thread will wait
//this will be synchronized block
sem.release(); allows another thread to aquire permit
I have a situation and I need some advice about synchronized block in Java. I have a Class Test below:
Class Test{
private A a;
public void doSomething1(String input){
synchronized (a) {
result = a.process(input);
}
}
public void doSomething2(String input){
synchronized (a) {
result = a.process(input);
}
}
public void doSomething3(String input){
result = a.process(input);
}
}
What I want is when multi threads call methods doSomeThing1() or doSomeThing2(), object "a" will be used and shared among multi threads (it have to be) and it only processes one input at a time (waiting until others thread set object "a" free) and when doSomeThing3 is called, the input is processed immediately.
My question is will the method doSomeThing3() be impacted my method doSomeThing1() and doSomeThing2()? Will it have to wait if doSomeThing1() and doSomeThing2() are using object "a"?
A method is never impacted by anything that your threads do. What gets impacted is data, and the answer to your question depends entirely on what data are updated (if any) inside the a.process() call.
You asked "Variable reference or memory is blocked?"
First of all, "variable" and "memory" are the same thing. Variables, and fields and objects are all higher level abstractions that are built on top of the lower-level idea of "memory".
Second of all, No. Locking an object does not prevent other threads from accessing or modifying the object or, from accessing or modifying anything else.
Locking an object does two things: It prevents other threads from locking the same object at the same time, and it makes certain guarantees about the visibility of memory updates. The simple explanation is, if thread X updates some variables and then releases a lock, thread Y will be guaranteed to see the updates only after it has acquired the same lock.
What that means for your example is, if thread X calls doSomething1() and modifies the object a; and then thread Y later calls doSomething3(), thread Y is not guaranteed to see the the updates. It might see the a object in its original state, it might see it in the fully updated state, or it might see it in some invalid half-way state. The reason why is because, even though thread X locked the object, modified it, and then released the lock; thread Y never locked the same object.
In your code, doSomething3() can proceed in parallel with doSomething1() or doSomething2(), so in that sense it does what you want. However, depending on exactly what a.process() does, this may cause a race condition and corrupt data. Note that even if doSomething3() is called, any calls to doSomething1() or doSomething2() that have started will continue; they won't be put in abeyance while doSomething3() is processed.
I need to clear a few basic concepts so as to check whether my understanding is correct or not.
1) Once a thread enters any synchronized method on an instance, no other thread can enter any other synchronized method on the same instance.
2) However, nonsynchronized methods on that instance will continue to be callable (by other threads). If yes, can I then say the whole object doesn't gets locked but only the critical methods which are synchronized.
3) Will I get the same behaviour as above for synchronized statement too:
synchronised(this){
// statements to be synchronised
}
or the whole object gets locked here with nonsynchronized methods on that instance not callable.
I think I am pretty confused with locking scope.
A lock only prevents other threads from acquiring that same lock -- the lock itself has no idea what it protects -- it's just something that only one thread can have. We say the whole object is locked because any other thread that attempts to lock the whole object will be unable to acquire that lock until it's released. Otherwise, your understanding is correct.
Your statements are correct. Only synchronized code becomes protected. The object is simply used as the synchronizing lock, and it is not itself "locked".
And yes, you get the same behavior for synchronized blocks on the same object. In fact, you can synchronize blocks in the code of one object using another object as the lock.
The code,
public synchronized void abc() {
...
}
it is conceptually same as,
public void abc() {
synchronized(this) {
}
}
In either of these cases the non-synchronized methods can be called when the monitor (in this case the object on which the method abc is called) is locked by a Thread executing a synchronized block or method.
Your understanding is correct. All three statements you made, are valid.
Please note one thing though, locks are not on methods(synchronized or non-synchronized). Lock is always on the object, and once one thread acquired the lock on an object, other threads have to wait till the lock is released and available for other threads to acquire.
Can anyone tell me if I'm right or not? I have two thread which will run in parallel.
class MyThread extends Thread {
MyThread() {
}
method1() {
}
method2() {
}
method3() {
}
approach(1):
run() {
method1();
method2();
method3();
}
approach(2):
run() {
//the code of method1 is here (no method calling)
//the code of method2 is here (no method calling)
//the code of method3 is here (no method calling)
}
}
class Test{
public static void main(){
Thread t1 = new Thread();
t1.start();
Thread t2 = new Thread();
t2.start();
}
}
method1, method2 and method3 don't access global shared data but their codes perform some write in local variable within the method section, thus I guess I can not allow overlap execution within the method section.
Thereby:
in approach(1): I need to make the methods (method1, method2 and method3) synchronized, right?
in approach(2): No need to synchronize the code sections, right?
If I'm right in both approach, using the approach(2) will give better performance, right?
Short answer: you don't need the synchronization. Both approaches are equivalent from a thread safety perspective.
Longer answer:
It may be worthwhile taking a step back and remembering what the synchronized block does. It does essentially two things:
makes sure that if thread A is inside a block that's synchronized on object M, no other thread can enter a block that's synchronized on the same object M until thread A is done with its block of code
makes sure that if thread A has done work within a block that's synchronized object M, and then finishes that block, and then thread B enters a block that's also synchronized on
M, then thread B will see everything that thread A had done within its synchronized block. This is called establishing the happens-before relationship.
Note that a synchronized method is just shorthand for wrapping the method's code in synchronized (this) { ... }.
In addition to those two things, the Java Memory Model (JMM) guarantees that within one thread, things will happen as if they had not been reordered. (They may actually be reordered for various reasons, including efficiency -- but not in a way that your program can notice within a single thread. For instance, if you do "x = 1; y = 2" the compiler is free to switch that such that y = 2 happens before x = 1, since a single thread can't actually notice the difference. If multiple threads are accessing x and y, then it's very possible, without proper synchronization, for another thread to see y = 2 before it sees x = 1.)
So, getting back to your original question, there are a couple interesting notes.
First, since a synchronized method is shorthand for putting the whole method inside a "synchronized (this) { ... }" block, t1's methods and t2's methods will not be synchronized against the same reference, and thus will not be synchronized relative to each other. t1's methods will only be synchronized against the t1 object, and t2's will only be synchronized against t2. In other words, it would be perfectly fine for t1.method1() and t2.method1() to run at the same time. So, of those two things the synchronized keyword provides, the first one (the exclusivity of entering the block) isn't relevant. Things could go something like:
t1 wants to enter method1. It needs to acquire the t1 monitor, which is not contended -- so it acquires it and enters the block
t2. wants to enter method2. It needs to acquire the 11 monitor, which is not contended -- s it acquires it and enters the block
t1 finishes method1 and releases its hold on the t1 monitor
t2 finishes method1 and releases its hold on the t2 monitor
As for the second thing synchronization does (establishing happens-before), making method1() and method2() synchronized will basically be ensuring that t1.method1() happens-before t1.method2(). But since both of those happen on the same thread anyway (the t1 thread), the JMM anyway guarantees that this will happen.
So it actually gets even a bit uglier. If t1 and t2 did share state -- that is, synchronization would be necessary -- then making the methods synchronized would not be enough. Remember, a synchronized method means synchronized (this) { ... }, so t1's methods would be synchronized against t1, and t2's would be against t2. You actually wouldn't be establishing any happens-before relationship between t1's methods and t2's.
Instead, you'd have to ensure that the methods are synchronized on the same reference. There are various ways to do this, but basically, it has to be a reference to an object that the two threads both know about.
Assume t1 and t2 both know about the same reference, LOCK. Both have methods like:
method1() {
synchronized(LOCK) {
// do whatever
}
}
Now things could go something like this:
t1 wants to enter method1. It needs to acquire the LOCK monitor, which is not contended -- so it acquires it and enters the block
t2 wants to enter method1. It needs to acquire the LOCK monitor, which is already held by t1 -- so t2 is put on hold.
t1 finishes method1 and releases its hold on the LOCK monitor
t2 is now able to acquire the LOCK monitor, so it does, and starts on the meat of method1
t2 finishes method1 and releases its hold on the LOCK monitor
You are saying your methods don't access global shared data and write only local variables so there is no need to synchronize them Because both the threads will be having their own copies of local variables. They will not overlap or something.
This kind of problem is faced in case of static/class variables. If multiple threads try to change the value of static variables at same time then there comes the problem so there we need to synchronize.
If the methods you're calling don't write to global shared data, you don't have to synchronize them.
In a multithreaded program, each thread has its own call stack. The local variables of each method will be separate in each thread, and will not overwrite one another.
Therefore, approach 1 works fine, does not require synchronization overhead, and is much better programming practice because it avoids duplicated code.
Thread-wise your ok. local variables within methods are not shared between threads as each instance running in a thread will have its own stack.
You won't have any speed improvements between the two approaches it is just a better organisation of the code (shorter methods are easier to understand)
If each method is independent of the other you may want to consider if they belong in the same class. If you want the performance gain create 3 different classes and execute multiple threads for each method (performance gains depends on the number of available cores cpu/io ration etc.)
Thereby: in approach(1): I need to make the methods(method1,method2
and method3) synchronized, right? in approach(2): No need to
synchronize the code sections, right?
Invoking in-lined methods v/s invoking multiple methods don't determine whether a method should be synchronized or not. I'd recommend you to read this and then ask for more clarifications.
If I'm right in both approach, using the approach(2) will give better performance, right?
At the cost of breaking down methods into a single god method? Sure, but you would be looking at a "very" miniscule improvement as compared to the lost code readability, something definitely not recommended.
method1, 2 and 3 won't be executed concurrently so if the variables that they read/write are not shared outside the class with other threads while they're running then there is no synchronization required and no need to inline.
If they modify data that other threads will read at the same time that they're running then you need to guard access to that data.
If they read data that other threads will write at the same time that they're running then you need to guard access to that data.
If other threads are expected to read data modified by method1, 2, or 3, then you need to make the run method synchronized (or them in a synchronized block) to set up a gate so that the JVM will set up a memory barrier and ensure that other threads can see the data after m1,2 and 3 are done.