Understanding "Thread affine abstractions"

I came across the following statement while reading the article on optimizing code for multicore machines (http://msdn.microsoft.com/en-us/magazine/cc163340.aspx).
Can someone kindly explain in other words what the writer is attempting to say here ?


["A task is created by supplying an associated action that can potentially be executed in parallel. The action is executed somewhere between the creation time of the task and the first call to the Wait method. The associated action may be executed in parallel on another thread, but there is a guarantee that the action will not migrate among threads. This is a useful guarantee since programmers can use thread affine abstractions like Windows critical sections without having to worry, for example, that the LeaveCriticalSection is executed in a different thread than the EnterCriticalSection. "]

I wanted a clarification on the sentence regarding thread affine abstractions. Can someone please let me know what that means and how it is related to the CriticalSection blocks ?

If a thread calls EnterCriticalSection, that same thread has to call LeaveCriticalSection. So it's just saying you don't have to worry about a "task" starting on one thread and finishing up on another.

Affinity = a close connection, relationship. As in, the "task" belonging to the thread in which it's running.

The link didn't work for me BTW.

gg

Hi CodePlug,

Thanks for the reply.

What you basically means in terms of code is that there is a function f() which could be executed by both thread A and thread B. But the concept of tasks as mentioned above will make sure that only thread A is able to execute f() to completion and only once it is complete will thread B be allowed to take over.

Seems like locking the critical section being implemented internally - is that not ?

I am repasting the link below. Hope you manage to open it this time.

http://msdn.microsoft.com/en-us/magazine/cc163340.aspx

Quote:

---

Originally Posted by humble_learner

This is a useful guarantee since programmers can use thread affine abstractions like Windows critical sections without having to worry, for example, that the LeaveCriticalSection is executed in a different thread than the EnterCriticalSection. "

---

This can't ever happen unless there is an error in the code.

If threadA acquires the lock on a cs (by calling EnterCriticalSection). If threadB attempts to acquire the lock, it will block until threadA has released the lock (by calling LeaveCriticalSection). Given this, threadB could only ever call LeaveCriticalSection if it was improperly coded (meaning threadB failed to initially call EnterCriticalSection before calling LeaveCriticalSection).

Much of the drudgery of dealing with thread synchronization can be made easier by using the RAII approach. By using RAII (Resource Acquisition Is Initialization), you only need to worry about locking and the scope of the locks; the unlocks happen automatically with the help of some small wrapper classes.

See the threading articles in my signature line for more info.