synchronization strategy

[sarvesh meens]

There are five libraries in our system. viz

01) communikator
02) FM
03) NM
04) UM
05) booter
06) application

Each of these libraries has a defined API - a Facade.
Libraries communicate with each-other thru their facade only.

FM is dependent on communikator.i.e.FM calls methods in communikator facade only.
NM is dependent on FM and communikator.i.e. calls methods in communikator and FM facades only.
UM is dependent on NM,FM and communikator.i.e. calls methods in communikator,FM and NM facades only.
booter is dependent on jars 1 thru 4.i.e. calls methods in communikator,FM,NM and UM facades only.
application is dependent on jars 1 thru 5.i.e. calls methods in communikator,FM,NM,UM and booter facades.

communikator spawns three daemon threads.viz.
* message thread - receive messages from server
* trap thread - receive traps from server
* connection manager- manage connection between communikator and server
Each of the these threads may traverse or land in any of the other five libraries.
application may spawn multiples threads.

None of the libraries are thread-safe and the entire application has been running without any problem so far.
We understand that threads may inter-leave and the libraries have to be synchronized.
This is where the dilemma is.
There are two ways to synchronize the libraries:

a) Traverse the flow of each of the thread and find where they inter-leave.
Synchronize only blocks/methods that occur where threads interleave and may lead to corruption(We have a fairly good understanding o\f how data may be corrupted)
In this approach we depend on the behvaiour of the system and synchronize only required blocks/methods

b) Ignore thread flow and synchronize all blocks/methods that may be corrupted in a multi-threaded environment.
In this approach we dont depend on the behvaiour of the systeam and synchronize all blocks/methods that contain vulnerable data.

Approach (b) is fairly straight-forward. Identifying data that will be corrupted by-theory is easy. But we may end up synchronizing \blocks where threads may never inter-leave. We end-up locking and unlocking resources un-necessarily.

Approach (a) is not easy. Traversing each thread spawned by communikator and application is enormous effort. Many a time,we dont eve\n konw how-many threads will be spawned by the application.

Which approach to choose?
Is there a tool to identify and highlight blocks where threads interleave?

Thanks in advance.

[Val�ry Urbain]

You should start by running some tools for monitoring the application and try finding all (most) resource contentions (CPU, memory, IO etc).
A description of Standard tools for monitoring JSE6 applications can be found here.
After you profiled the application and identified the problematic areas, then you can narrow your refactoring effort only towards those areas.

[Nicholas Jordan]

Any approach that is fairly straight-forward is THE approach to use. ( beyond question )

As for: Identifying data that will be corrupted by-theory is easy. But we may end up synchronizing where threads may never inter-leave. We end-up locking and unlocking resources un-necessarily.
It is my understanding the the JAVAC is an effective parallelizing compiler, and would therefore be able to remove sync() where there is no inter-leaving [ a remarkably descriptive term ]

Unless the app is a high-performance, mission-critical on the main path of everything that happens everywhere, I would not give a great deal of thought to avoiding sync() thinking that extra effort there is going to pay off. (the) Supposed "cost" of synchronization is usually really trivial compared to the energy people spend trying to avoid it. The effort is much better spent designing human interfaces that effect the the design intent in the observer's mental state and considering avoiding disk head accesses where reasonably achievable.

[sarvesh meens]

Thanks for your insights.

We are going for approach (b) i.e igonoring thread-flow and synchronising everything that is vulnerable. Reasons for adopting this approach:

01) Cost of synchronization is not high. Unnecessary sync statements are removed by the compiler.
02) Approach (b) is the standard practice adopted.


Val�ry,the article on "Monitoring and Managing Java SE 6 Platform Applications" is very useful. We dont see any performance issue in our application. It is our logical understanding that there are threading issues and the application will break in multi-threaded environment. So,we are not profling the application now.

Nicholas,the info on parallelization compiler is interesting. This provokes another question: If the compiler can remove un-necessary sync statements,why can't it introduce sync statement wherever necessary automatically?

[Jim Yingst]

Hm, I don't know that the compiler can remove unnecessary synchronization. Nick is just speculating there, I believe. I've never heard of this actually being done in the JVM. Even if it were to occur in some cases, it would be a good deal more complex to add synchronization in a useful, meaningful way. At best you'd probably add overhead of synchronization in a lot of places you didn't really need it; at worst you'd have a good chance of errors which would either allow unsafe behavior, or possibly cause deadlock.

We get enough problems with people thinking their code is "thread safe" just because they use poorly-designed classes like Vector, which have the synchronization at the wrong level to be really useful. If people thought that the compiler was taking care of thread safety, many would give up on proper thread safety analysis entirely. This isn't the sort of job that can be done effectively with partial compier help where the details are not fully understood by the programmer - if there's synchronization being added at all, it needs to be a complete thread-safe solution, or it will just get in the way and undermine the programmer. And I have no reason to believe that any existing compiler is capable of providing a complete thread-safe solution.

If such a thing as automatic thread safety were going on in the compiler, it would be a major feature that Sun should announce loudly. If they haven't, i would assume that nothing like that is going on.

[Nicholas Jordan]

[JY:]... as posted ...
I was absolutely sure I had heard that in Threads and Synchronization before or I would not have been so direct.

Inter-leaving Threads and the data have to be synchronized, generally, and the spotting of such cross-locks would be better done by a machine, no ?

[JY:]We get enough problems with people thinking their code is "thread safe" just because they use poorly-designed classes like Vector, which have the synchronization at the wrong level to be really useful. If people thought that the compiler was taking care of thread safety, many would give up on proper thread safety analysis entirely. This isn't the sort of job that can be done effectively with partial compier help where the details are not fully understood by the programmer - if there's synchronization being added at all, it needs to be a complete thread-safe solution, or it will just get in the way and undermine the programmer.

So I sorta made a judgment call here that the original poster would follow up and the sophistication of the orignal analysis suggests that follow-up would be done, as it appears to me is being done. We cannot be effective in resolving risk-analysis issues in a world-model that isolates the occipital cortex from Life under 22 undexplained wind shield failures. . At 450 knots at 22,000 foot altimiter reading, one's face is subject to becoming unrecognizable software.

I go on the table here and state plainly that deadlocks from Thread crossings derived from attempting to obtain n-tuple locks can and should only be done by compiler code-path analysis , and an optimal implementation would provide compile time switches which would allow wildcatting of Threads with the clear implication that the Program/Coder/Designer would be given tools for spotting such data-corruption risks.

No machine can make real and reasoned assessment of data-corruption risks, and a billion pounds of mineral in a Train-Scheduling task is a real and immediate burden for Java Community if we are to move up to compliance with contemporary civilization's Earth-Bound existence. The fact that Jim and I are having this discussion in front of a poster who can so adequately express their design burden proves that the JVM specification needs work in this area. The behavior of threads, particularly when not correctly synchronized, can be confusing and counterintuitive. That spells nasty suprises, and there is no replacement for a machine that can Traverse the flow of each of the thread and find where they inter-leave.

[JY:]   Double-checked locking and Singleton   Synchronization has gotten much cheaper over the years.... (snip) Synchronization is not that big a deal, performance-wise, and much convoluted, hard-to-maintain code has been written needlessly by people trying to avoid it., ... to which I continue: but we would need an assessment from the original poster as to what the risks of data-corruption are for this paticular Thread to be worked in productive manner.

I have given this a great deal of thought, and the only way to detect corruption at runtime that I can think of is to do final currentlyExecutingThread = java.lang.Thread.currentThread();at construction or function entry, and if this.currentlyExecutingThread != java.lang.Thread.currentThread(); at function return: The entire department is in a clearly unacceptable reporting position if some anomalies appear in run-time performance and responsiveness (when using the JVM where mission critical needs require a more deterministic risk model.)

To say the least, this should have been discovered in design phase and I am positioning that escape analysis is proof-beyond-requirements that the tools and techniques of compiler design can and will discover this risk if single-threaded and stop-the-world in nature behaviour is not acceptable to sarvesh meens' teams synchronization strategy, who has a fairly good understanding of how data may be corrupted, which is unusual outside of postgrad cs.

The remark on which I base my work here came shortly after I saw Henry suggest to a poster to google for escape analysis and was made in wait() without notify()/notifyAll(): In the area of threads, the JVM will just *not* synchronize a method or block, even if the method or block is synchcronized. This is actually not a problem. If an object can't escape a method call, it will not be shared between threads anyway. HW on Monday, June 18, 2007 9:55 AM

In order to avoid neutron locking in a quantum harmonic oscillation as we usually do, I will defer to Henry to speak for the masters and wonder what Pat would have to say about this. There are subtle race conditions that may not be apparent to the original posters concurrent mark-sweep collector.

{ anyone reading this please note that Jim and I are working at the boundaries here and understand that what may appear to be contention is just an opportunity for progress }
[ November 13, 2007: Message edited by: Nicholas Jordan ]

[Nicholas Jordan]

[sarvesh meens:]why can't it introduce sync statement wherever necessary automatically?

Because machines can't think.

[Jim Yingst]

Originally posted by Nicholas Jordan:
[JY:]... as posted ...
I was absolutely sure I had heard that in Threads and Synchronization before or I would not have been so direct.

Inter-leaving Threads and the data have to be synchronized, generally, and the spotting of such cross-locks would be better done by a machine, no ?

Oh, come on. Can't you be bothered to give some clue as to what you're replying to? Quoting is not hard, really. It should not be left as an excercise for the reader to figure out what the heck you're talking about.

I can't really speak to wht you may have heard, or thought you heard. I can only say that I have never heard or seen any evidence that the compiler or JVM does any deletion or insertion of synchronization code. If you have anything resembling evidence (as opposed to vaguely-remembered hearsay), please share it.

It does seem possible that some thread-safety-related tasks could be prefomed automatically. (Though Id be concerned about making sure programmers had a clear understanding of what was going on bhind the scenes.) But let's not confuse what we think could or [/i]should[/i] be possible with what actually occurs in present-day systems.

[Nicholas Jordan]

[Jim Yingst:]   Oh, come on. Can't you be bothered to give some clue as to what you're replying to? Quoting is not hard, really. It should not be left as an excercise for the reader to figure out what the heck you're talking about.

Well it was intended as a courtesy, the words are right there and I thought it wasteful of eyespace to repaste what is in view. It certainly was not intened as you are taking it or appear to be taking it.

[Jim Yingst:]   I can't really speak to wht you may have heard, or thought you heard. I can only say that I have never heard or seen any evidence that the compiler or JVM does any deletion or insertion of synchronization code. If you have anything resembling evidence (as opposed to vaguely-remembered hearsay), please share it.

Later in the post I recovered the citation and mark it clearly, including hyperlink to the cited conversation. ( which was from HW, who may be able to provide citation )


[Jim Yingst:]   It does seem possible that some thread-safety-related tasks could be perfomed automatically.

I suggest such tasks be limited to spotting inter-leaving either reporting those or adding default sync() by a compile time switch.

[Jim Yingst:]   (Though Id be concerned about making sure programmers had a clear understanding of what was going on behind the scenes.) But let's not confuse what we think could or should be possible with what actually occurs in present-day systems.

It appears to me that JAVA can take a caveat whenever it wants to on this as the JVM is a generalization of computer science and runs on architectures over which it may not have design influence. My belief rests on the statement: In the area of threads, the JVM will just *not* synchronize a method or block, even if the method or block is synchcronized. This is actually not a problem. If an object can't escape a method call, it will not be shared between threads anyway. by HW on Monday, June 18, 2007 9:55 AM

The discusssion is hyper-linked right there, you should be able to find it if you'll quit driveling on my reputation long enought to look.
[ November 13, 2007: Message edited by: Nicholas Jordan ]