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:

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:

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.

What Other People Are Searching For

[ local search ] learning coldfusion 8
[ local search ] coldfusion 8 cfthread problem
[ local search ] global scopes cfthread
[ local search ] referring to variables in cfthread
[ local search ] referring to threads
[ local search ] coldfusion 8 cfthread scope
[ local search ] coldfusion 8 thread scope

You Might Also Be Interested In: