Re: Running concurrent Mulithreaded Application
Re: Running concurrent Mulithreaded Application
- Subject: Re: Running concurrent Mulithreaded Application
- From: LD <email@hidden>
- Date: Thu, 1 Sep 2005 02:19:42 +1000
Hi there,
On 31/08/2005, at 11:21 PM, David LeBer wrote:
On 31-Aug-05, at 9:00 AM, Praveen Boppana wrote:
Yes, Crash is probably little too strong.
When we didn't have this option setup.
If the application receives requests at the same time, causing the
threads to lock and marking application non responsive.
We had to restart the application every time to make it to work.
<...>
Also be aware that with concurrent response handling *enabled* you
will need to ensure that your application is fully thread safe and
that you are religiously locking your EC's (not to imply that you
weren't :-)
I will now defer to Chuck's comments in this post on Kieran
Kelleher's blog: <http://homepage.mac.com/kelleherk/iblog/
C1216817469/E1769995701/>
Hmm... there's a problem with the Chuck's advice (sorry Chuck):
"Using synchronized methods is the most common / simple way of
preventing simultaneous access...If you add any mutable values to
Application, then you must provide synchronized methods to access them."
Unfortunately, Java's synchronized keyword lends itself to abuse
unless you understand what it's doing. You need to understand that
the synchronized methods block all access to the instance until that
lone thread has left the building! Doing this on your Application
instance is probably less than desirable.
e.g., The following two examples are identical...
// Foo instances block _all_ other requests
// until _a_ thread that was accessing any synchronized
// method has left the building!
public class Foo {
int a; // should be independent from b but isn't
int b; // should be independent from a but isn't
int c; // read-only needn't be synchronized
// blocks all other access to Foo instance
public synchronized int criticalA() {
return a--;
}
// blocks all other access to Foo instance
public synchronized int criticalB() {
return b++;
}
// requests are queued instead of concurrent
// if another thread invokes above methods.
public int readC() {
return c;
}
}
// no different
public class Foo {
int a, b, c;
public int criticalA() {
synchronized ( this ) {
return a--;
}
}
public int criticalB() {
synchronized( this ) {
return b++;
}
}
public int readC() {
return c;
}
}
A better solution (among others)...
public class Me {
private Object lockA = new int[];
private Object lockB = new int[];
int a, b, c;
public int criticalA() {
synchronized( lockA ) {
return a;
}
}
public int criticalB() {
synchronized( lockB ) {
return b;
}
}
// concurrent access now!
public int readC() {
return c;
}
}
For a more in depth perusal of these things: See "Programming Java
Threads in the real world" series... e.g., Part 3:
http://www.javaworld.com/javaworld/jw-11-1998/jw-11-toolbox_p.html
Other parts...
http://www.javaworld.com/isearch?
site=javaworld&nh=10&st=1&ms=1&tid=1&rf=0&qt=Programming Java%
20Threads in the real world, Part&
with regards,
--
LD
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden