Understanding Value Binding Within CFThread
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.
Want to use code from this post? Check out the license.
Reader Comments
Nice writeup, Ben.
@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.
Thanks Ben, I knew you would have some reference to this :)
@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).