code complexity only goes up when you don't know what your doing.
That's very helpful to know.
thanks i gues

actually my motivation in posting that is all in your reply.
@TLE: I am not so clear on your question
so I decided to poke anound as perhaps it was just me, in any case I disagree the motivation of the
answer given. Yes most of the time the option is dismissed for good reasons.
Don't use threads unless you know exactly why you're doing it.
actually I'd go with 'Don't use any unless you know exactly why you're doing it.' being a good practice.
to cut this offtopic stuff sort,
don't avoid multi threading because it's.. scary. this just obscures the engineering process.
Wenn using complexity to be more complex you need a point of reference.. Reguarding software metrics,
I can give examples of cases where cyclomatic complexity is equal or less that of the non-threaded variant.
Classifying something as 'complex', or rather to complex is subjective even more so wenn mixing in the
fact that transformation likely shifts the points of complexity around having various effects on the perspective.
ok thats not really cutting it short,
Although there are situations where multiple threads allow to make things easier to understand ...
although by the sound of it the state pattern suggestion is a good choice it only replaces the flagging bit with something more OO and has little influence on the multithreaded case the state switching or the boolean assigning.