Re: Running concurrent Mulithreaded Application
Re: Running concurrent Mulithreaded Application
- Subject: Re: Running concurrent Mulithreaded Application
- From: Chuck Hill <email@hidden>
- Date: Wed, 31 Aug 2005 10:00:52 -0700
Hi,
On Aug 31, 2005, at 9:19 AM, LD wrote:
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."
While you are technically correct, I doubt this would have much
practical ;-) impact in most cases. In my experience, any
synchronized methods at the application level are short lived (finish
quickly) and there are many other bottle necks in WO (EOF for
example) that will impact performance long before synchronized
methods in Application will. YMMV.
Chuck
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:
40global-village.net
This email sent to email@hidden
--
Practical WebObjects - a book for intermediate WebObjects developers
who want to increase their overall knowledge of WebObjects, or those
who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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