Re: Threading contexts
Re: Threading contexts
- Subject: Re: Threading contexts
- From: Jim Magee <email@hidden>
- Date: Tue, 20 May 2003 21:10:00 -0400
On Tuesday, May 20, 2003, at 12:54 AM, Wally Crooze wrote:
Continuing on from the locking and synchronization primitives... I
have the need to be able to associate particular information with a
thread which is specific to my kext project.
In other OSes an interface is provided to allow information stored
which doesn't effect the control of the thread. I found the following
interfaces which set/retrieve thread_t->saved.misc:
extern void thread_set_cont_arg(int);
extern int thread_get_cont_arg(void);
These aren't used anywhere in xnu, but thread_t->saved is a union and
is used for other information. Are these interfaces expected to be
used for miscellaneous thread information within my own code? Also,
can I treat this int as a void* ?
You can only use this to save information while you are causing the
thread to block. Some such blocks can occur at continuation points
(where the kernel stack is thrown away). These are the continuation
arguments that you can use to build context back up when the thread
resumes. If you aren't blocking the thread, you can't claim ownership
of these fields.
Unfornately neither the Kernel Programming guide and Threading
Architecture Technotes describe a method of associating an information
context to the thread.
That's because there isn't any such mechanism today. We are looking at
providing a generalized version of thread-local-data for the kernel
environment. But we don't have anything like that now.
An example for this use is part of my sema implementation requires to
store whether the thread was woken normally or by an (software)
interrupt from my code.
This is a situation where use of the cont_arg mechanism would be
appropriate. But you might want to use the wait_result value for this
indication (depending upon what sleep/wakeup mechanism you are using).
Remember that unless you block threads as "uninterruptible", the
signal/Mach thread_abort mechanisms may do the interruptions without
your wakeup code ever getting involved. You must deal with those
cases. They will result in a wait_result of THREAD_INTERRUPTED. If
you want to "poke at" a thread without making it look like a signal,
the THREAD_RESTART wait_result is commonly used.
--Jim
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.