Oh, you are starting a thread from the code behind!..
Well, that would not be an Ext.NET limitation, but rather a limitation inherent from ASP.NET pages' life cycle, that server-side cannot really initiate communication with the client. There always must be the client on the initiating side of anything that will change the client's view. That's related to the 'ASP.NET page life cycle'.
As for the literature for this, its here:
ASP.NET Page Life Cycle Overview.
As workarounds to this limitation it would be necessary to make your thread change a session variable (I am not 100% sure it would be on scope when you instantiate concurrent task) or something which a timed client-side task probes before performing a task or updating the control.
Assuming the session can be touched from the task, you can keep a variable to indicate new label value as 'null' and once you call the code behind to add the task, also add a recurrent AJAX or direct call to probe that variable until it has value.
Once it has a value, for example, the same direct call could perform whatever is wanted once the long running task is done or (little worse) return "true" so another dedicated task is called to collect the results and update the controls. And as the task is fulfilled, then stop the recurring call to the code behind background action.
I have worked in an Ext.NET project which used services handers (ashx) to perform this task, although I do not remember in details how it did that.
Alright, enough blah-blah-blah. Here's an example we have that implements something like what I'm saying. And it uses a session variable as the trigger.
Progress bar - server side update
I hope I am finally able to help you! :) Just give a word otherwise.