On Mon, May 31, 2010 at 11:56 AM, Barney Boisvert <[email protected]> wrote: > "locks aren't necessary for simple reads" to prevent memory > corruption. They ARE necessary if you have a potential race > condition.
It's also worth noting that whether you need to lock or not depends on the type of data being shared and the way it is accessed. It's a hard problem to understand. Here's a real world example: FW/1 - my framework - is thread safe under normal operation. onApplicationStart() performs all the basic initialization and any subsequent cache updates are exclusively locked. Reads don't need to be locked because cached data is set once and not subsequently updated (modulo the usual VAR scope issues in user-supplied CFCs, of course). However, when you force the framework to reinitialize in a regular request and you are using a bean factory, it is possible for the bean factory to be removed for a very short period before it is recreated (by user code) and it is possible for another thread to get in and create a component and attempt to autowire it (using said missing bean factory) which leaves the newly created object in a bad state. Possible but not very likely, except under heavy traffic or if you have the framework in reload-on-every-request mode and you have a lot of ajax calls in your pages (generating multiple concurrent requests while the framework is reloading multiple times). I have to figure out a way to reliably execute the code so that scenario goes away - because locking access / updates is going to have a performance impact for the mainstream use case (I actually have a solution in mind which doesn't involve locking because I can rely on how the code executes during a reload even in the present of multiple concurrent requests). > then read-only locks are absolutely needed in certain cases. And this is the problem for most CFers: what are those 'certain cases'? If they don't know, they'll tend to lock everywhere and performance will suck and CF will get a black eye for 'performing badly'. It is a hard problem and web developers really *do* need to learn about this stuff... > In reality, you only get to avoid the lock when you have a > read on a single shared scope variable. (depending on its type and how updates are performed on it) > If you have a read and then a > write, you MUST lock the read. Not in all cases. If the variable is atomic and it's value can either be safely predicted in a multi-threaded scenario - or it's value doesn't "matter" (e.g., it's cached data that doesn't have to be 100% up-to-date in real time - rather than a critical accumulator value) - then you still don't need to lock. > I don't want to be an anal retentive pedant, but this is REALLY > important. We agree there :) -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwoo ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology-Michael-Dinowitz/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:334151 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
