Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at cf.Objective() 2014 (Bloomington, MN) with:

Understanding Value Binding Within CFThread

By Ben Nadel on
Tags: ColdFusion

Yesterday, Bjorn Jensen brought a very interesting ColdFusion 8 CFThread problem to my attention. He was launching threads within a CFLoop and then using the loop index value within the code of each individual thread. What he was seeing was that the value of the index variable seemed to be completely unpredictable. If you are not used to programming in an asynchronous environment (and I think most ColdFusion developers are not), this is complete confusing. The only reason I had any idea what was going on was because I do a lot of programmatic event binding in Javascript and similar problems crop up.

The real problem here is understanding when a variable value is actually being evaluated. For the code within a CFThread, variables are evaluated ONLY at the time that the variable-referencing line is executed, not when it is defined. In typical procedural programming, these events are generally one and the same; however, in a multi-threading environment with thread queuing, a variable's usage might be defined at one point and then not executed until a later time.

This is what was causing Bjorn's problem. His CFLoop was starting and completing before ColdFusion 8 executed all of the threads. This means that for any of the threads that were lower in the thread queue, by the time their code was executed, the CFLoop index value held a value that was one greater than the TO attribute of the CFLoop tag. And, since the variable value is evaluated only at variable execution time, many of the threads referenced the same value.

To demonstrate this issue, I have put together a demo in which we create threads that reference a VARIABLES-scoped value:

  • <!--- Launch 20 threads. --->
  • <cfloop
  • index="intIndex"
  • from="1"
  • to="20"
  • step="1">
  •  
  •  
  • <!--- Launch ASYNCHRONOUS thread. --->
  • <cfthread
  • action="run"
  • name="thread#intIndex#">
  •  
  • <!---
  • Randomly sleep a thread. This will ensure that the
  • index value is not firing instantly.
  • --->
  • <cfif RandRange( 0, 1 )>
  •  
  • <!--- Sleep thread for half second. --->
  • <cfthread
  • action="sleep"
  • duration="#(1 * 500)#"
  • />
  •  
  • </cfif>
  •  
  • <!---
  • Store the variable in the THREAD scope. This will
  • bind the value of the index variable to the pass-
  • by-value count.
  • --->
  • <cfset THREAD.IndexValue = intIndex />
  •  
  • </cfthread>
  •  
  • </cfloop>
  •  
  •  
  • <!--- Wait for all the threads to join the current page. --->
  • <cfthread
  • action="join"
  • />
  •  
  •  
  • <!---
  • Loop over all the threads and output the index value
  • that was bound to the thread-scoped variable.
  • --->
  • <cfloop
  • index="intIndex"
  • from="1"
  • to="20"
  • step="1">
  •  
  • Thread #intIndex# :
  •  
  • #CFTHREAD[ "thread#intIndex#" ].IndexValue#<br />
  •  
  • </cfloop>

In the code, we are randomly sleeping some of the threads to simulate an environment in which threads may not execute in the same order in which they were defined. Running the above code, we get the following output:

Thread 1 : 2
Thread 2 : 3
Thread 3 : 21
Thread 4 : 21
Thread 5 : 6
Thread 6 : 21
Thread 7 : 21
Thread 8 : 21
Thread 9 : 21
Thread 10 : 21
Thread 11 : 21
Thread 12 : 13
Thread 13 : 14
Thread 14 : 21
Thread 15 : 16
Thread 16 : 17
Thread 17 : 21
Thread 18 : 21
Thread 19 : 21
Thread 20 : 21

Notice that the majority of threads stored the value, 21, which was the index value after the loop finished executing.

To get around this, you should avoid referring to variables outside of the currently executing thread. In the above case, we were referring the CFLoop index variable which was defined outside of the currently executing thread. Instead of referring to the VARIABLES-scoped value, we should pass the value into the thread using ColdFusion 8's CFThread custom tag attributes:

  • <!--- Launch 20 threads. --->
  • <cfloop
  • index="intIndex"
  • from="1"
  • to="20"
  • step="1">
  •  
  •  
  • <!---
  • Launch ASYNCHRONOUS thread, but this time, pass the
  • index value into the thread using a custom attribute.
  • This will get the variable value to evalute a the
  • time the thread is defined.
  • --->
  • <cfthread
  • action="run"
  • name="thread#intIndex#"
  • indexvalue="#intIndex#">
  •  
  • <!---
  • Randomly sleep a thread. This will ensure that the
  • index value is not firing instantly.
  • --->
  • <cfif RandRange( 0, 1 )>
  •  
  • <!--- Sleep thread for half second. --->
  • <cfthread
  • action="sleep"
  • duration="#(1 * 500)#"
  • />
  •  
  • </cfif>
  •  
  • <!---
  • Store the variable in the THREAD scope. This time,
  • refer to the ATTRIBUTES scope rather than the
  • VARIABLES scope since the variable was passed into
  • the CFThread tag at the time of thread definition.
  • --->
  • <cfset THREAD.IndexValue = ATTRIBUTES.IndexValue />
  •  
  • </cfthread>
  •  
  • </cfloop>
  •  
  •  
  • <!--- Wait for all the threads to join the current page. --->
  • <cfthread
  • action="join"
  • />
  •  
  •  
  • <!---
  • Loop over all the threads and output the index value
  • that was bound to the thread-scoped variable.
  • --->
  • <cfloop
  • index="intIndex"
  • from="1"
  • to="20"
  • step="1">
  •  
  • Thread #intIndex# :
  •  
  • #CFTHREAD[ "thread#intIndex#" ].IndexValue#<br />
  •  
  • </cfloop>

Notice here that we are passing the variable in using ColdFusion 8's custom CFThread tag attributes. This loads that value into the thread's ATTRIBUTES scope. But, more importantly, it's forcing ColdFusion to evaluate the variable at the moment that the individual threads are defined. Running the above code, we get the following output:

Thread 1 : 1
Thread 2 : 2
Thread 3 : 3
Thread 4 : 4
Thread 5 : 5
Thread 6 : 6
Thread 7 : 7
Thread 8 : 8
Thread 9 : 9
Thread 10 : 10
Thread 11 : 11
Thread 12 : 12
Thread 13 : 13
Thread 14 : 14
Thread 15 : 15
Thread 16 : 16
Thread 17 : 17
Thread 18 : 18
Thread 19 : 19
Thread 20 : 20

This time, it works just as expected. So remember, try to pass variables into a CFThread tag if you are going to refer to them within the tag execution.

Tweet This Deep thoughts by @BenNadel - Understanding Value Binding Within CFThread Thanks my man — you rock the party that rocks the body!



Reader Comments

@Jeff,

Thanks. I think CFThread is a big shift in mentality for a lot of people, so it's really important to explore this type of thing. It's double important since you can't really output the screen from within an asynchronous thread. But this stuff is really cool.

Reply to this Comment

@DeepDown,

No problem my man; as a rule of thumb, I typically pass all my thread-based variables as part of the CFThread tag attributes. You just have to be careful when you are dealing with what are typically pass-by-reference values since CFThread attributes are passed-by-VALUE across the board (including structs and CFCs).

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.