No, I don't think that's true. Wouldn't really scale well or make sense. It also wouldn't make threads magically be handled correctly. A thread pool alone would have 0 to do with how something handles "synchronized" blocks.
On 11/16/06, Jeff Poetker <[EMAIL PROTECTED]> wrote:
I'm not sure it would be a huge difference based on your hypothetical situation. I believe most app servers (I know weblogic does) serves requests from a thread pool, which generally has much less than 1000 threads - I believe by a couple of orders of magnitude... So you're probably not really going to actually have 100's of threads waking up to get that lock. On Nov 15, 2006, at 10:22 PM, Jesse Kuhnert wrote: > 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 --------------------------------------------------------------------- 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
