Yeah, I think it would be a huge difference - but only when the load on your server is especially high or you are dealing with multiple cpus. (Who knows, maybe sun fixed synchronized in recent jre's)
The biggest difference and easiest example I always use is a simple scenario. Let's say you have a synchronized block (and not method, I won't get into why that is particularly harmful wrt locking up the entire object vs a single block of logic) and 1000 concurrent requests to get access to that block. With "synchronized" the first thread that wins gets the lock. When it releases the lock all 999 of the remaining sleeping threads are woken up and each one attempts to get the lock. Again, only 1 wins and everyone else goes to bed. Keeping in mind that each thread has its own heap space to be managed, native counterparts to interact with, etc...This is a lot of processing in the grand scheme of things when thinking about it on the micro level. The biggest thing backport-util (and which is the exact same library included in >= 1.5 jres by default) does is handle this particular logic. Much like "synchronized" all 999 threads will go to sleep after the first one wins. The difference is that only one thread will be woken up when it is done. So...wake up 999 threads vs 1. There's a lot more but that's the basic gist as I've understood it. On 11/15/06, Nick Westgate <[EMAIL PROTECTED]> wrote:
Canonical use of ReentrantLock here wouldn't be any better than synchronize(this), would it? I'm wondering what you have in mind. Anyway, my company is only just starting to look at using Java 5, so I'm not really familiar with the concurrent classes yet. Jeff: Thanks for your testing. I was finally going to put 3.04 in production after our next round of development! It would be handy if something like double-checked locking was guaranteed to work. (I think it's valid in Python.) Cheers, Nick. Jesse Kuhnert wrote: > You could always just use the apis provided by backport-util-concurrent as > well....It makes it almost trivial to do these tasks, all without being > retarded about thread management. (as would be the default behavior > exhibited when using the "synchronized" keyword ) > > On 11/14/06, Jeff Poetker <[EMAIL PROTECTED]> wrote: >> >> Ok... Well, I'm not sure I'm ready to go there just yet... I did want to >> send an update to whom it may concern... >> >> I worked with our load test environment today, and was able to reproduce >> my >> problem fairly easily. We ran a set of about 20 virtual users in a script >> that would have all 20 request a page at the same time, wait for all >> 20 to >> get responses, then send all 20 at another page. All, on a freshly >> started >> server, with no page objects pooled yet. >> >> The repetitive method errors started showing up almost immediately with >> the >> 3.0.4 code. >> >> So, next I overloaded the getter in the engine that returns the >> DefaultComponentClassEnhancer, and had it return my own >> ComponentClassEnhancer. My version works the way 3.0.3 did, with the >> double-checked locking code. (I know this code is not guaranteed to work, >> but because we hadn't seen this problem before, it seemed like it had >> been >> working for us). >> >> I ran the same test with the double-checked locking code. No problems. >> (FYI >> - I was testing against a dual Xeon (NetBurst, not Core) server and the >> JRockit VM on RedHat Linux). >> >> Ok, so, this "fixes" my problem, but I've been studying up on this >> double-checked locking thing, and get that it isn't really safe to assume >> it >> will work... So, I tried doing the only thing that most of the articles I >> read said you could do - synchronize the whole thing. So I re-implemented >> my >> custom ComponentClassEnhancer to syncrhonize the method in question... >> >> Of course, this also works... It also made my simple 20 user test take 2 >> minutes longer. :( >> >> My test of course was a worst case, hitting new pages with nothing >> pooled. >> Tomorrow I'm going to try both solutions with a more realistic load, and >> find out if the synchronization solution is really going to hurt us or >> not. >> >> >> On 11/13/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: >> > >> > Yep, a much more efficient means of doing it would be to use >> > http://dcl.mathcs.emory.edu/util/backport-util-concurrent/ . It seems >> like >> > this is crossing over on the annotation exceptions being thrown when >> > caching >> > is disabled as well. (though maybe the solution for t4 won't be the >> same >> > as >> > t3 since t4 is based around hivemind. ) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
