To best of my knowledge,
is implemented by automatic mapping on threads, and we know that on Windows .NET threads are implemented on the base of OS threads (not fibers or some .NET specific mechanism). That said, the system should not guarantee that every time a task is executing its time slice, the current thread being executed is the same in all cases.
You see, you can easily try to confirm it by experiment, but the problem is: if you observe that a current thread is sometimes different, it would confirm it, but if you observe that the current thread is the same for the same task, it would not prove anything.
Indirectly, what I say is confirmed by Microsoft documentation: http://www.codeproject.com/script/Answers/Post.aspx?aid=407532
Behind the scenes, tasks are queued to the ThreadPool, which has been enhanced with algorithms (like hill-climbing) that determine and adjust to the number of threads that maximizes throughput. This makes tasks relatively lightweight, and you can create many of them to enable fine-grained parallelism. To complement this, widely-known work-stealing algorithms are employed to provide load-balancing.
From all this documentation article, I don't see a reason why a task instance should be guaranteed to run by the same thread. I think it would be safest to say: this is implementation-dependent.
If you go so far to try it out, of find out exact documentation explicitly explaining this matter, please notify me by commenting on this answer.