Calling java timer in a synchronized block of codes - java

If I have a parent block of codes called A, A is synchronized. And in A, I executes a child block of code called B. Am I right to assume that B will be synchronized also?
If in A I have a timer to delay the execution of B in a certain of t time, is there a chance that B gets executed later when A already finished?
Thank you very much.
P/S: Sorry the the unclear code, this is how it should look like
synchronized A{
Timer timer = new Timer();
timer.schedule(new TimerTask() {
#Override
public void run() {
B block
}
}, 2*60*1000);
}

Depends. If the block B is a block of code within method like this, then yes... it will be synchronized.
public synchronized void methodA() {
// Block B
{
// some code
}
}
If it's another method like the following, then no:
public synchronized void methodA() {
methodB();
}
public void methodB() {
// Block B code
// Nothing prevents an unsynchronized method from calling this method
// at same time as methodA() holds lock on `this` object
}
Unless methodB is also marked synchronized or called from another synchronized method (eg/ public synchronized methodC()) or another synchronization mechanism is used, then methodB() is not synchronized.
Those are just the simplest cases. You're better off posting example code since 'block' is not well defined by default and the type of synchronization lock (implicit on this via synchronized method vs. explicit object lock) makes a difference.
But, your last line sounds like you're asking about synchronous vs. asynchronous execution of code which, while related to threading and synchronized blocks, is a different concept.
In that case, it depends on what happens in block A ... if new threads are created to execute block B then anything can happen with the timing of code execution. If no threads are created, it's safe to assume that block A will not complete before block B.
Edit: based on code now posted ... the synchronized A block will only ensure the Timer threads get created one at a time. But, unless there's something special about the Java Timer framework, there's nothing there that will prevent two threads from executing the B block in the run method simultaneously ... so make sure that the contents are thread safe.
That is, don't assume that just because different instances of Timer are created in a synchronized block with the same delay, they won't get into the run method at the same time. If the B block accesses external un-thread-safe code (eg. static methods, disk access), you could have surprises.
As Amm Sokun mentioned in other answer, A{} will return before
Block B executes.

Block B will be executed after A has finished executing, this is because in method A you are just scheduling B to be run after 2*60*1000 milli, and timer will take care of executing B after 2*60*1000 milli

Related

synchronization mechanism in Java

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.

java threading lock variable properly

Thread A does:
class A{
public String value;
public void methodA(String value){ //lets say value="test"
this.value=value;
//some code
// Thread B interrupts
System.out.println(value); // prints "haha" but I want it to be "test"
}
}
Thread B does:
class B{
public void methodB(){
a.setValue("haha");
}
}
methodB and methodA are some kinds of listener methods, which are executed in separate Threads.
How can I make sure that value does not change, as long as methodA has not finished? But I want also that "haha" is assigned to value afterwards. So I want B to wait till A has finished methodA and then assign "haha" to value.
The easiest way is to use 'synchronized' keyword on method that change the value of a field.
For example we have class that stores the data:
public class Data {
String value = "";
public synchronized void setValue(String val) {
this.value = val;
System.out.println(val);
}
}
And then Threads only use this method to update the value. Only one thread at the time can execute this method (no interrupts).
If you want to propagate this on two methods (like I suppose is the case). You can use two options. Or use synchronized on both methods or use external lock object.
If you want to be sure, that for example thread A has to be first to execute, you can use CountDownLatch object, which will stop other threads until thread A won't decrement the latch.
There are many ways to handle synchronization. You should be more precise to what you want to achieve and what kind of scenario you want to handle. Like for example - Is a.setValue("haha") a method from class A?
I would also recommend to look at documentation about concurrency https://docs.oracle.com/javase/tutorial/essential/concurrency/ .
If you just want methodA() to complete before methodB() is called, then you should call both methods from the same thread. In general, if you want your program to do certain things in a certain order, the best way to accomplish it is
to do all of the things in a single thread.
On the other hand, you might want both threads to work in parallel most of the time, but there might be one particular point that you don't want thread B to pass until thread A gets there. The Java standard library provides a variety of different synchronization objects that you could use. E.g., java.util.concurrent.CountDownLatch.
Initialization:
CountDownLatch countDownLatch=new CountDownLatch(1);
threadA.start();
threadB.start();
Thread A:
doSomeStuff();
methodA();
countDownLatch.countDown();
doSomeMoreStuff();
ThreadB:
doSomeOtherStuff();
countDownLatch.await();
methodB();
doSomeMoreOtherStuff();
The doSomeStuff() and doSomeOtherStuff() calls could happen concurrently, and the doSomeMoreStuff() and doSomeMoreOtherStuff() calls could happen concurrently, but the methodA() and methodB() would be serialized in this case.

Java Threading - Synchronized code

Why do you have to specify, which object has locked a synchronized block of code?
You don't have to specify which object has locked a synchronized method as it is always locked by 'this' (I believe).
I have two questions:
Why can't you block a none static method with an object other than
'this' ?
Why do you have to specify the object that has blocked
synchronized code?
I have read chapter nine of SCJP for Java 6, but I am still not clear on this.
I realize it is probably a basic question, but I am new to Threading.
Why can't you block a none static method with an object other than 'this' ?
You can:
public void foo() {
synchronized (lock) {
...
}
}
Why do you have to specify the object that has blocked synchronized code?
Because that's how the language designers chose to design the language. synchronized, when used on instance methods, implicitely uses this as the lock. synchronized when used on a block must explicitely specify the lock.
You can.
The code
synchronized foo() {
// some stuff
}
Is logically equal to code
foo() {
synchronized(this) {
// some stuff
}
}
I said "logically" because these 2 examples generate different byte code.
If method foo() is static synchronization is done of class object.
However you can wish to create several synchronized blocks that are synchronized on different objects into one class or even into one method. In this case you can use synchronized (lock) where lock is not this:
foo() {
synchronized(one) {}
///..........
synchronized(two) {}
}
You can specify any object you want which should have the lock on the synchronized code block. Actually, you shouldn't use synchronize(this) at all (or maybe be careful about it, see Avoid synchronized(this) in Java?).
EVERY object has a lock on which you can synchronize:
final Object lock = new Object()
synchronized ( lock ) { ... }
If you want to synchronize the whole method, you cannot say on which object, so it is always "this" object.
synchronized foo() {....}
The first way of locking is better, by the way.
It is not recommended to lock each method with this as it reduces the concurrency in most cases. So it is recommended to use Lock Stripping in which only the specific part of the code that needs to be protected is kept in synchronized block.
It is a practice that is explained well in Java Concurrency in Practice. But note this book is useful only when you have some basic experience with threading.
Some nuggets to keep in mind:
Do not overuse synchronization
use method level synchronization only when the whole method needs to be protected
Use different locks to protect two unrelated entities, which will increase the chances of concurrency. or else for reading or writing two unrelated entities threads will block on same lock.
public void incrementCounter1(){
synchronized(lockForCounter1){
counter1++;
}
}
public void incrementCounter2(){
synchronized(lockForCounter2){
counter2++;
}
}
I think your two questions actually are same. let's say if you wanna synchronized a method m of object a between multiple threads, you need a common base system or channel that threads can talk to, this is actually what object lock offers, so when you wanna a method of a object be synchronized there is no need for another object lock to do this, because the object you access itself has this lock, that's how and why lanuage designed.
while synchronized a block is not the same thing, threads can have different talking base other than this object itself, for instance, you can set a same object as synchronized object lock for synchronized block, so all objects of this Class can be synchronized at that block!
From the concurrency tutorial, the Synchronized methods part:
To make a method synchronized, simply add the synchronized keyword to its declaration:
public class SynchronizedCounter {
private int c = 0;
public synchronized void increment() {
c++;
}
public synchronized void decrement() {
c--;
}
public synchronized int value() {
return c;
}
}
If count is an instance of SynchronizedCounter, then making these methods synchronized has two effects:
First, it is not possible for two invocations of synchronized methods on the same object to interleave. When one thread is executing a synchronized method for an object, all other threads that invoke synchronized methods for the same object block (suspend execution) until the first thread is done with the object.
Second, when a synchronized method exits, it automatically establishes a happens-before relationship with any subsequent invocation of a synchronized method for the same object. This guarantees that changes to the state of the object are visible to all threads.
Simply put, that's how synchronization in Java works.
You don't have to specify which object has locked a synchronized method as it is always locked by 'this' (I believe).
True for instance methods, for static methods it locks upon the class object.
Why can't you block a none static method with an object other than 'this' ?
Note that:
public synchronized void increment() {
c++;
}
is equivalent in behavior to:
public void increment() {
synchronized(this) {
c++;
}
}
In this code snippet you can replace this with any object you wish.
Why do you have to specify the object that has blocked synchronized code?
Some, let's call it critical, block of code is to be ran only sequentially, but in uncontrolled concurrent environment it is possible that it will be ran in parallel. That's why synchronization mechanisms exists.
So we can divide the code like this:
the code safe to be ran in parallel (default situation)
the code that has to be synchronized (must be marked somehow)
That markation is made via the synchronized keyword and the corresponding lock object.
If you have two different critical code blocks that must not be ran together, they'll both have the synchronized keyword, and let's say they have the same lock object.
While the first block is executing, the lock object becomes "locked". If during that time the second block needs to get executed, the first command of that code block is:
synchronized(lock) {
but that lock object is in locked state because the first block is executing. The execution of the second block halts on that statement until the first block finishes the execution, and unlocks the state of the lock object. Then the second block may proceed with the execution (and lock the lock object again).
That mechanism is called the mutual exclusion and the lock is a general concept not tied to the Java programming language.
The details of the "lock object locking" process can be found here.
You can lock with any instance of an object but programmers usually
use this or locker...
Because it restrict access to that part of code by other threads
(unit of code processing) so you make sure whole of that part run in
consistence and nothing (i.e. a variable) would be alerted by another thread.
Consider:
a = 1;
a++;
Thread one reaches second line and you expect a = 2 but another thread executes first line and instead of 2 you have a = 1 for first thread and a = 2 for second thread. Now:
synchronized (whatever)
{
a = 1;
a++;
}
Now second thread would be blocked from entering into the code block (synchronized body) until first one leaves it (release the lock).

Differences between synchronized(this) and synchronized(objectReference)

I'd like to better understand the mechanics of what actually happens when thread enters the synchronized(this) block vs synchronized(someObjectReference) block.
synchronized (this) {
// Statement 1
// Statement 2
}
synchronized (someObjectReference) {
// Statement 1
// Statement 2
}
As i understand it: (am i missing something? am i wrong?)
In both cases, only 1 thread can access synchronized block at a time
When we're synchronizing on someObjectReference :
Only 1 thread at a time may access/modify it in this block
Only 1 thread at a time may enter this block
What other mechanics are there please?
synchronized (objectReference) {
// Statement 1 dealing with someObjectReference
// Statement 2 not dealing with someObjectReference
}
In the example above, does it make any sense adding statements not dealing with mutex into the synchronized block?
There's only a difference when you mix the two together.
The single, basic rule of synchronized(foo) is that only one thread can be in a synchronized(foo) block for the same foo at any given time. That's it. (The only caveat maybe worth mentioning is that a thread can be inside several nested synchronized(foo) blocks for the same foo.)
If some code is inside a synchronized(foo) block, and some code is inside a synchronized(bar) block, then those pieces of code can run simultaneously -- but you can't have two threads running code in synchronized(foo) blocks simultaneously.
In both cases, only 1 thread can access synchronized block at a time
Not really. For exemple, when synchronizing on "this", 2 threads can access to the same block if they have 2 different instances of the same class. But yes, for one instance, there will be only one access to the block. And there will also have only one acess to any synchronized block on this
"Synchronized" means that only 1 thread can have access to any synchronized block on the same instance. So if you have 2 synchronized block in 2 different source files, but on the same instance, if one thread is inside one of those blocks, another thread cannot access to both synchronized block
About "what to do within a synchronized block" : do only things dealing with the synchronized object. Any other instruction that doesn't need synchronization will lock the ressource for nothing, an potentially create a bottleneck
Synchronize basically means program request to take a lock on the specified object...If a Thread is not able to enter any synchronized block then that means any other thread has already taken lock on the specified object..BLock of code specify that inside this region a thread can enter if lock is successfully acquired..
In both cases, only 1 thread can access synchronized block at a time
--Depend on the object to be locked availability
One important thing to note about synchronizing on this deals with visibility. Lets say you have a class A and it synchronizes on this. Any code that uses A has a reference to the object A is using to lock on. This means it is possible for a user of A to create a deadlock if they also lock on the A instance.
public class A implements Runnable {
public void run() {
synchronized (this) {
// something that blocks waiting for a signal
}
//other code
}
}
public class DeadLock {
public void deadLock() {
A a = new A();
Thread t = new Thread(a);
t.start();
Thread.sleep(5000); //make sure other thread starts and enters synchronized block
synchronized (a) {
// THIS CODE BLOCK NEVER EXECUTES
// signal a
}
}
}
Where as, if you always synchronize on a private member variable, you know that you are the only one using that reference as a lock.

What does synchronized()/wait()/notifyAll() do in Java? [duplicate]

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Java Synchronization
I'm reading the book Beginning Android Games.
It uses synchronized() a lot but I don't really understand what it does. I haven't used Java in a long time and I'm not sure if I ever used multithreading.
In the Canvas examples it uses synchronized(this). However in the OpenGL ES example, it creates an Object called stateChanged and then uses synchronized(stateChanged). When the game state changes it calls stateChanged.wait() and then stateChanged.notifyAll();
Some code:
Object stateChanged = new Object();
//The onPause() looks like this:
public void onPause()
{
synchronized(stateChanged)
{
if(isFinishing())
state = GLGameState.Finished;
else
state = GLGameState.Paused;
while(true)
{
try
{
stateChanged.wait();
break;
} catch(InterruptedException e)
{
}
}
}
}
//The onDrawSurface looks like this:
public void onDrawFrame(GL10 gl)
{
GLGameState state = null;
synchronized(stateChanged)
{
state = this.state;
}
if(state == GLGameState.Running)
{
}
if(state == GLGameState.Paused)
{
synchronized(stateChanged)
{
this.state = GLGameState.Idle;
stateChanged.notifyAll();
}
}
if(state == GLGameState.Finished)
{
synchronized(stateChanged)
{
this.state = GLGameState.Idle;
stateChanged.notifyAll();
}
}
}
//the onResume() looks like this:
synchronized(stateChanged)
{
state = GLGameState.Running;
startTime = System.nanoTime();
}
The synchronized keyword is used to keep variables or methods thread-safe. If you wrap a variable in a synchronized block like so:
synchronized(myVar) {
// Logic involing myVar
}
Then any attempts to modify the value of myVar from another thread while the logic inside the synchronized block is running will wait until the block has finished execution. It ensures that the value going into the block will be the same through the lifecycle of that block.
This Java Tutorial can probably help you understand what using synchronized on an object does.
When object.wait() is called it will release the lock held on that object (which happens when you say synchronized(object)), and freeze the thread. The thread then waits until object.notify() or object.notifyAll() is called by a separate thread. Once one of these calls occurs, it will allow any threads that were stopped due to object.wait() to continue. This does not mean that the thread that called object.notify() or object.notifyAll() will freeze and pass control to a waiting thread, it just means these waiting threads are now able to continue, whereas before they were not.
When used like this:
private synchronized void someMehtod()
You get these effects:
1. First, it is not possible for two invocations of synchronized methods on the same object to interleave. When one thread is executing a synchronized method for an object, all other threads that invoke synchronized methods for the same object block (suspend execution) until the first thread is done with the object.
2. Second, when a synchronized method exits, it automatically establishes a happens-before relationship with any subsequent invocation of a synchronized method for the same object. This guarantees that changes to the state of the object are visible to all threads.
(Taken from here)
You get a similar effect when you use a synchronized block of code:
private void someMethod() {
// some actions...
synchronized(this) {
// code here has synchronized access
}
// more actions...
}
As explained here
Java (which Android is based on) can run under multiple threads that can utilize multiple cpu cores. Multi-threading means that you can have Java doing two processes at the exact same moment. If you have a block of code or method that you need to ensure can only be operated by one thread at a time, you synchronize that block of code.
Here is the official Java explanation from Oracle
It's important to know that there is a processor/io costs involved with using synchronized and you only want to use it when you need it. It is also important to research what Java classes/methods are thread safe. For instance, the ++ increment operator is not guarateed to be thread safe, whereas you can easily create a block of synchronized code that increments a value using += 1.
only one thread can be active and inside block synchronized by given object.
calling wait stops gives up this right and deactivates current thread until someone call notify(all)()
Then the inactive thread start wanting to run in the synchronized block again, but is treated equaly with all other threads that wants it. Only one somehow chosen (programmer cannot influence nor depend on which one) actualy gets there.
Synchronized keyword in java is used for 2 things.
First meaning is so called critical section, i.e. part of code that can be accessed by one thread simultaneously. The object you pass to synchronized allows some kind of naming: if one code is run in synchronized(a) it cannot access other block that is into synchronized(a) but can access block of code into synchronized(b).
Other issue is inter-thread communication. Thread can wait until other thread notifies it. Both wait and notify must be written into synchronized block.
It was a very short description. I'd suggest you to search for some tutorial about multithreading and read it.
The keyword synchronized, together with the wait and notify operations form a nonblocking condition monitor, a construct useful for coordinating multiple threads.

Categories

Resources