Vineet Tyagi wrote:
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Campbell Ritchie wrote:What have you read about threading? Have you read the Java Tutorials or Brian Goetz’s book?
Vineet Tyagi wrote:I know my question was not specific and not according to the rules of forum. I will do home work and search for it. Then i will be back with the exact problem.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
Vineet Tyagi wrote:I know my question was not specific and not according to the rules of forum. I will do home work and search for it. Then i will be back with the exact problem.
Great. Thanks for listening, and I look forward to helping you out when you do.
Winston
BalaMurali dhar wrote:we can prevent deadlock in multithreading by using synchronization keyword
Vineet Tyagi wrote:
BalaMurali dhar wrote:But i think synchronization the root of deadlock.. synchronisation is used to prevent concurrency problems
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
BalaMurali dhar wrote:we can prevent deadlock in multithreading by using synchronization keyword
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
Vineet Tyagi wrote:
BalaMurali dhar wrote:But i think synchronization the root of deadlock.. synchronisation is used to prevent concurrency problems
Simple answer is: You can only prevent deadlock by using prevention measures.
In a situation involving only one call to a synchronized method it can't occur; the problem usually occurs when you have calls to more than one sync'ed method in the same piece of code; and the reason is that synchronized on a method doesn't have sufficient granularity to prevent it.
The old database trick I was taught around the K-T extinction event was to always, always, always obtain locks in the same sequence.
You can simulate this by creating object locks (or indeed using ReentrantLock's, which seems to be favoured now) for each "protected" piece of code, and using synchronized blocks rather than methods. It has to be said, that this can sometimes cause you to obtain unnecessary locks, but it is safe.
Other than that: analysis, analysis, analysis.
Winston
Campbell Ritchie wrote:There should be some deadlock prone code in the tutorials link I sent you earlier.
Vineet Tyagi wrote:Thanks for such a useful info.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
Vineet Tyagi wrote:Thanks for such a useful info.
I should perhaps add that your pieces of "protected code" will actually be dealing with 'things' (ie, objects) that you want to protect, and that's where the analysis comes in. If you have 4 things that you want to synchronize: A, B C and D, create a lock for each, and just make sure that every piece of code that has to update them (or read "verified" values) obtains the locks in the same sequence.
Assuming everyone follows the rules, you can ignore locks below the scope; so, assuming that A,B,C,D is the order in which you lock, if you have a piece of code that needs to update C, you can ignore D, but you must include A and B.
As you can imagine, this means that determining the best sequence also takes a bit of analysis. I believe it's called the "paranoid" rule.
It's also highly likely that there are methodologies more suited to Java code, but it's the one I was taught, and it's dead simple to remember.
Winston
The first person to drink cow's milk. That started off as a dare from this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|