aspose file tools*
The moose likes Threads and Synchronization and the fly likes Threads and Synchronization Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Threads and Synchronization" Watch "Threads and Synchronization" New topic
Author

Threads and Synchronization

Phil Hopgood
Ranch Hand

Joined: Jul 14, 2008
Posts: 47
Afternoon all.

Suppose I have a runnable class that has methods A and B, say.

Method A is not synchronized in the method declaration but has some portion of code that is synchronized. This synchronized portion of code may be executed or it may not depending on the path taken through method A.

Method B is has no synchronization at all.

I declare one instance of this runnable job, DoSomethingClever, and start two threads, x and y with DoSomethingClever, i.e. the same job.

Now suppose thread x is running and enters the bit of synchronized code in method A and obtains a lock on DoSomethingClever and then gets sent to the runnable state.

Now thread y becomes runnable and needs to call method B, the one that's not synchronized. Will thread y have to wait until thread x has released it's hold on DoSomethingClever?

Supplementary Questions:

1. Can threads only access runnable objects? or is it just the thread's job that has to be runnable?

2. Can you assign a method or a portion of code of a method as being synchronized in an unrunnable class?

Idiot questions I'm sure but thanks for your help, can't tell you how helpful you all are ....

Regards,
Phil
Thomas Thevis
Ranch Hand

Joined: Sep 02, 2008
Posts: 87
Hey Phil,

I think, you mix up some concurrency concepts the wrong way.
With synchronized you are able to protect resources from beeing accessed in parallel. Therefore, synchronized would usually occur in classes providing access to the resources. Threads can be thought of as working units working in parallel. If these workers could access all resources at all time, all kinds of dangerous things could happen (have a search for race conditions, for instance). With synchronization you are able to ensure that only one of several threads synchronized on the same object or class is able to execute this code in parallel. Synchronizing a complete method corresponds to synchronize on the current class instance (this).

Thomas


SCJP 5.0, SCJD in progress
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4176
    
  21

Originally posted by Phil Hopgood:
...Method A is not synchronized in the method declaration but has some portion of code that is synchronized. ... Method B is has no synchronization at all.

I declare one instance of this runnable job, DoSomethingClever, and start two threads, x and y with DoSomethingClever, i.e. the same job.

Now suppose thread x is running and enters the bit of synchronized code in method A and obtains a lock on DoSomethingClever ... Now thread y becomes runnable and needs to call method B, the one that's not synchronized. Will thread y have to wait until thread x has released it's hold on DoSomethingClever?


No. The only code that would block would be code also synchronized on the same lock. So, assuming methodA uses synchronized(this) {...} then other methods declared as synchronized, or with similar synchronized (this) blocks would wait. Since methodB does not have any synchronization it would not block.




Originally posted by Phil Hopgood:
Supplementary Questions:

1. Can threads only access runnable objects? or is it just the thread's job that has to be runnable?

2. Can you assign a method or a portion of code of a method as being synchronized in an unrunnable class?

Idiot questions I'm sure but thanks for your help, can't tell you how helpful you all are ....

Regards,
Phil


1) Not exactly sure what the question is. The Runnable represents the working unit of a Thread. The Thread can only us Runnable as a unit. But any class can be accessed from a thread once it is kicked off...

2) Yes. Any method/block of code in any class can be synchronized. The method/block should be synchronized if it is intended to run in a multi-threaded environment and it accesses non-local resources (or it should be well documented as not being synchronized and as such not thread-safe so any callers would know to synchronize appropriate calling code).


Steve
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38363
    
  23
Don't know . . . but I think your topic would sit better on the threads forum, so I am moving you.
Phil Hopgood
Ranch Hand

Joined: Jul 14, 2008
Posts: 47
Thanks for that Guys,

your answers make infinite sense...

I think I'll go play with threads for a bit now and try out the above scenario.

Regards,
Phil.
arulk pillai
Author
Ranch Hand

Joined: May 31, 2007
Posts: 3219
In Java programming, each object has a lock. A thread can acquire the lock for an object by using the synchronized keyword. The synchronized keyword can be applied in method level (coarse grained lock � can affect performance adversely) or block level of code (fine grained lock). Often using a lock on a method level is too coarse. Why lock up a piece of code that does not access any shared resources by locking up an entire method. Since each object has a lock, dummy objects can be created to implement block level synchronization. The block level is more efficient because it does not lock the whole method.

The JVM uses locks in conjunction with monitors. A monitor is basically a guardian who watches over a sequence of synchronized code and making sure only one thread at a time executes a synchronized piece of code. Each monitor is associated with an object reference. When a thread arrives at the first instruction in a block of code it must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code. When the thread leaves the block, no matter how it leaves the block, it releases the lock on the associated object.


Q. Why synchronization is important? Without synchronization, it is possible for one thread to modify a shared object while another thread is in the process of using or updating that object�s value. This often causes dirty data and leads to significant errors. The disadvantage of synchronization is that it can cause deadlocks when two threads are waiting on each other to do something. Also synchronized code has the overhead of acquiring lock, which can adversely affect the performance


Java Interview Questions and Answers Blog | Amazon.com profile | Java Interview Books
Phil Hopgood
Ranch Hand

Joined: Jul 14, 2008
Posts: 47
OK, this is getting spookily like my life, I start to think I understand it then...... wham! something happens and I'm confused again!

Arulk, thanks for your input. This now prompts me to ask a few more idiot questions just to clarify things, so I hope you can bare with me.

I understand the need for synchronization, in the old days we used to use semaphores to do this ..... a bit more clumsy than synchronization but the end result was similar. I understand about the granularity of synchronization.

What's confusing me at the present is this: as far as I can see a class and therefore each instance of that class, has only one lock. If within a class there is a piece of synchronized code, whether it's a block or a method, and a thread accesses that piece of code then that thread obtains a lock on ...... what?

Just the piece of synchronized code that the thread has entered?

or

The whole object, all it's code, including unsynchronized and, assuming that there are other unrelated synchronized bits of code, other synchronized bits of code?

or

Just the synchronized bits

Regards and thanks for all your help,
Phil.
Vijitha Kumara
Bartender

Joined: Mar 24, 2008
Posts: 3825


Phil Hopgood :
as far as I can see a class and therefore each instance of that class, has only one lock


No. Each object has it's own lock. On the other hand each class has a Class lock which is different from object lock and per class.

thread accesses that piece of code then that thread obtains a lock on ...... what?


thread should aquire the lock of that object if the method/block in a instance method otherwise Class lock for that class if that's a static block/method.


SCJP 5 | SCWCD 5
[How to ask questions] [Twitter]
Carey Evans
Ranch Hand

Joined: May 27, 2008
Posts: 225

Each instance has its own lock, a kind of hidden field on Object. If it were implemented with semaphores, it could look like this: The lock isn't on the code itself at all.
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4176
    
  21

Just to add to the posts that were already made,

Every object (instance of any class) has a lock and a monitor. So to take advantage of the fine-grained locking mechanism synchronized blocks can use your don't have to use:

which is what a synchronized method does. Instead, you could have several Objects whose only reason for existence is to be used as a lock:

Any code synchronized on the addressLock would block while this updateAddress method runs, while any code synchronized on the nameLock would not.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Threads and Synchronization