helene@umiacs.umd.edu (Helene Young-Myers) (05/26/91)
I found a problem with thread_assign() that some of you
may want to know about.
It is fatal for thread_assign() to assign a thread to a
processor set that the thread is already assigned to. In
this case, Mach forgets to reset a state variable,
thread->may_assign. The next time a kernel operation is
performed on the thread, the requesting thread goes to sleep
forever, which makes the task an uninterruptable process.
The task cannot be terminated, so the processors assigned to
the task are never released. The next time a cpu_server
function is called by another task, the cpu_server goes into
an infinite loop. Mach must be rebooted to correct the
situation.
Some may wonder why one would assign a thread to a
processor set that the thread is already assigned to. This
happens when there are more C threads to be assigned than
there are processor sets, and some C threads terminate
before others are forked. Because the C Threads package
recycles Mach threads for efficiency, a new C thread may be
the same Mach thread as a previously terminated C thread.
So, if one is assigning each C thread to a processor set as
the C thread is forked, it is possible that the actual Mach
thread will be assigned to a processor set that the Mach
thread is already assigned to.
The way to get around the problem right now is to keep
track of the Mach threads that are assigned to each
processor set. The Mach thread port ID is gotten by calling
thread_self().
CMU is now aware of this problem.
Helene