Enthuware

I think #4 is more correct because i1=i2 and k1=k2 is always the case when the print statement in workWithoutLock method is executed. So we are certain that i and k will never be printed.

j1=j2 or j1!=j2: both cases could occur. So j could be printed.

#2 is not wrong but it's a more general case of #4. Also #2 hinted that i and k could be printed because it states that one cannot be certain whether the letters are printed but said nothing about i and k will not be printed???

Thanks,

Tony,

I am sorry but I did not understand what you mean.

#4 is not correct because it is possible that i1 is not equal to i2 and/or k1 is not equal to k2 because the workWithoutLocks method does not use locks and so one thread may execute i1 != i2 when the other thread has only done i1++.
-Paul.

I see
Thanks.

Can you please explain volatile? The explanation I find online is that volatile variables are "sort of" synchronized but it doesn't seem like it in the question.

When a regular i.e. non-volatile variable is accessed by two threads, there is no guarantee that one thread will ever see its new value updated by the second thread. So it is possible that one thread updates an int from 1 to 2, but the second thread will always see 1. It will never see 2.

Volatile fixes the above issue. It guarantees that if one thread updates a volatile variable then any other thread will definitely see the new value after the update is complete.

HTH,
Paul.

So you mean that you can always be certain that var is 10 when both threads have exited in the code above?

No, volatile ensures visibility but not timing. So missed updates are still possible. Timing is ensured by synchronization.

Volatile is a lower cost option and is useful when the delay in viewing the updated value is acceptable. For example, if you have a continually running loop in a thread that has to stop after a variable is updated by another thread and if a few extra iterations are ok, you should make the variable volatile.

Ok. Thanks!

I just wanna ask here aquiring lock on static object means the same as acquiring lock on the class, right?

No, lock on the class means lock on the Class object for that class (See this if you have any confusion about it: http://stackoverflow.com/questions/4453 ... lang-class ).
Lock on a static object is the lock on that particular object (nothing to do with the Class object).

Thanks though I don't want to get into the details of Class since it is used more in reflection and since reflection is not listed in the syllabus I'd rather look into it after the exam.

I am very puzzled about this question. Are there not two threads each having his own object 'TestClass', so they dont share the instance variables ? Is that right and it is the static declarer of i1,i2.. that makes the threads share these ?

Yes, there are two threads created using two TestClass objects. But there are no instance fields in the given code!! Also, instance fields are not shared between instances. Each instance gets its own copy of instance fields
Yes, i1, i2, j1, j2, k1, k2 are all static and are shared by the two TestClass isntances.

I try to figure out the behaviour of synchronized(lock1) and synchronized(lock2). Does synchronized on a static monitor will block thread using different object instance and thread using same object instance?

he only way a letter could be printed would be if the method workWithoutLocks() was executed between the time the first and the second variable was incremented.

Do you mean thread1 increment the first variable and thread2 execute condition of if statement?

>Does synchronized on a static monitor will block thread using different object instance and thread using same object instance?
Sorry, I am not able to understand what you mean by this.
>Do you mean thread1 increment the first variable and thread2 execute condition of if statement?
Yes.

admin wrote: ↑

Tue Mar 12, 2019 10:10 pm

>Does synchronized on a static monitor will block thread using different object instance and thread using same object instance?
Sorry, I am not able to understand what you mean by this.
>Do you mean thread1 increment the first variable and thread2 execute condition of if statement?
Yes.

By that I mean, lock1 is a static field; therefore, it is shared among the instance of TestClass.
If Thread1 and Thread2 are created by same object, Thread1 acquire the lock and access the synchronized block. Thread2 can not access.
If Thread1 and Thread2 are created by different object, Thread1 acquire the lock and access the synchronized block. Thread2 can not access since static lock share among the instances.

So there is no way to access the synchronize block (use static object as a lock) unless the lock is released?

There are two synchronized blocks and they are using two different locks - lock1 and lock2.

admin wrote: ↑

Tue Mar 12, 2019 10:47 pm

There are two synchronized blocks and they are using two different locks - lock1 and lock2.

Yeah, Sorry, I mean conceptually, if I have a synchronized block use a static lock.