Matheus Souza

Ranch Hand
+ Follow
since Mar 06, 2012
Matheus likes ...
Eclipse IDE Java Ubuntu
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
2
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Matheus Souza

Hey folks, I'm going to have the OCJA 7 exam, and I wanted to know from the people that hava already taken this exam where they had studied?

Thanks =D
9 years ago
Hey folks, I'm going to have the OCJA 7 exam, and I wanted to know from the people that hava already taken this exam where they had studied?

Thanks =D

Norbert Muench wrote:

Matheus Souza wrote:This is not what meant. I want to know if I lock an method syncronized, the whole set of static members would be locked too?


I think you misunderstand how locking works. If one thread holds a lock to an object, it doesn't prevent other threads from modifying any of the objects member variables. It just prevents other threads from aquiring a lock to the same object. And threads will only aquire a lock when starting a synchronized block or synchronized method.

Take the following code as an example:


Now imagine you have two threads, thread 1 and thread 2. Thread 1 has just called MyClass.staticSyn1() and is in the middle of working through that method. So it holds a lock to the MyClass class object.
If thread 2 would start running now, it could modify the static member MyClass.si1. The fact that thread 1 holds the lock on the MyClass class object doesn't come into play here at all. Thread 2 could also call MyClass.static1(), because that class method isn't synchronized.
But what happens, if thread 2 tries to call MyClass.staticSyn1(), MyClass.staticSyn2() or syn1() on any object of type MyClass?
At the start of the synchronized block, the thread would try to aquire a lock on MyClass.class. That lock is already held by thread 1 however. So in this case thread 2 would be moved from the running state to the blocked state. Once thread 1 releases the lock on MyClass.class, thread 2 would aquire the locks and would be moved from blocked to runnable (and eventually to running).



I think that I got it. Thanks for the effort on the explanation =D

Paul Clapham wrote:

Matheus Souza wrote:So if I create new instace of MyClass, the synchronized methods would be locked already?



I'm not sure quite what this means, but let me answer one of the questions it might mean:

No, creating an object will not automatically cause any code to acquire any locks it didn't already have.

If it meant something else, please correct my guess.



This is not what meant. I want to know if I lock an method syncronized, the whole set of static members would be locked too?

Norbert Muench wrote:

Matheus Souza wrote:I have another question: when I use the syncronized keyword in a static member it means that all my template (static member - variables and methods) are lockeds?


No, it means that threads executing the synchronized method need to aquire a lock on the class object.



So if I create new instace of MyClass, the synchronized methods would be locked already?
I have another question: when I use the syncronized keyword in a static member it means that all my template (static member - variables and methods) are lockeds?

Norbert Muench wrote:Same as you would call any other method.
The thread code still might get stuck in the call to wait() though, as there is no guarantee that the notifyAll() wouldn't be excuted before the wait().



I got it. Thanks for the explanation =D
Morning guys, I was doing another ExamLab mock and this question appeared:


It says that the answer is: Ready to print, Now printed. The explanation says that the wait() is wainting for an Trd instance, and the notifyAll() use a Thread instance. I didn't get it. Can anyone explain to me what happened?

Thanks

Matthew Brown wrote:Because wait() releases the lock, and that thread only re-acquires the lock when it's woken up (after the main thread releases it).

You can only call wait(), notify() and notifyAll() from within a synchronised block. So wait() would be entirely useless if it didn't release the lock, as no other thread would ever be able to get the lock to call notify().



That's right, I forgot that wait() releases the lock.

Thanks Matthew =D
Morning folks. I was doing an mock on ExamLab then this question appeared:


It says that the output is: DAEBC. But my question is: Isn't the object s1 locked when the thread starts, by calling synchronized(this) ? How thread main can call stnchronizes(s1) if it has already been locked?

Thanks

Anayonkar Shivalkar wrote:

rimantas grebliunas wrote:IMO x variable is static so it's value the same for all objects. The last constructor set x to 0 and then started all threads, thats why result 000000.


How did I miss this?

Thanks rimantas grebliunas for the correction.



Thanks you guys, I got it. This is a very tricky question, insn't it? =]
Hey guys, I was doing an mock from ExamLab and this question appeared:


It says that the answer is: 000000

Can anyone explain to me what happened?

Thanks

Ankit Garg wrote:See if this diagram helps...



Man you're awsome, I got it. Thanks for the diagram it helps a lot.
Hey guys I was doing an mock from ExamLab and this question appeared:



The answer is 3, but I one found 1 object eligible for the colection. Can anyone knows the others 2?

Thanks

Matthew Brown wrote:

Matheus Souza wrote:Alright, but why the expression inside the print() method is evaluated first? It is not always in this way, is it?


Yes, it it. You can only pass a single value to print(), not an expression. So the expression has to be evaluated first. You can't print something until you know what it is.



Well, at this point I'm thinking that the expression in print() method is executed right to left. I'm a little confuse now =[