Andrew Scott wrote: > Then your a fool in the making. > > Ok, lets say we have 2 threads running. > > Thread number one is checking to see if application.flag is true or not, it > sees it as true it gets hafl way through its process the second thread while > running at the same time has now changed this value halfway through the cfif > condition.
But now you are changing the scenario. The scenario was: > <cfset application.flag = true /> > no on its own that can not cause a race condition, but if somewhere else > there is a read on that variable somewhere then that will cause a race > condition. You are suddenly adding a second thread that changes the value of application.flag to your scenario. Which is incidentally exactly the same as the third condition I described. Your email wasn't wrong per se, but the scenario you described was incomplete and hence you were jumping to a conclusion that wasn't warranted. > That my friend is a typical example of a race condition, dont be fooled as > Ben says lock it. If I depend on it being the same during the entire request, I will probably still not lock it, but make a local copy. Only if I need it to be both the same and recent will I resort to locking. Jochem ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Create Web Applications With ColdFusion MX7 & Flex 2. Build powerful, scalable RIAs. Free Trial http://www.adobe.com/products/coldfusion/flex2/?sdid=RVJS Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:275264 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
