On 5/28/05, Bill Rawlinson <[EMAIL PROTECTED]> wrote: > Why the duplicate <cfif...> block?
Because it's needed :) > Is this because of the potential that someone else just edged you out and > actually set the application variable while you were setting your lock? Yes, you don't want to lock on every thread so the first <cfif> will catch most cases but during initialization, you could indeed have two threads both hit the outer <cfif> and both succeed so one locks and the other waits. The first thread hits the second <cfif> and succeeds - and does the initialization. Then it releases the lock, the second thread gets the lock and hits the second <cfif> and fails - which is as you want. Multithreaded stuff is hard. Some people think you should just do <cflock> <cfif> init </cfif> </cflock> but that causes *every* request to lock which single-threads your entire application. Definitely not desirable. Hope that's a good enough explanation? -- Sean A Corfield -- http://corfield.org/ Team Fusebox -- http://fusebox.org/ Got Gmail? -- I have 50, yes 50, invites to give away! "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
