Re: pthread spinlock calls on mac os 10.3
Re: pthread spinlock calls on mac os 10.3
- Subject: Re: pthread spinlock calls on mac os 10.3
- From: Terry Lambert <email@hidden>
- Date: Tue, 13 Dec 2005 11:25:55 -0800
On Dec 13, 2005, at 1:29 AM, Amol Gajewar wrote:
Does pthread spinlock calls on mac os 10.3 are available.
No. According to POSIX:
[SPI] Spin Locks
The functionality described is optional. The functionality described
is also an extension to the ISO C standard.
If your software is capable of using pthread_spin_* style locking, the
code should include <unistd.h> and protect itself from using these
functions if the value of _POSIX_SPIN_LOCKS is not *at least*
200112L. You can do this at compilation time using the preprocessor by:
#include <unistd.h>
#if ((_POSIX_SPIN_LOCKS - 200112L) >= 0L)
/* it is OK to use functions beginning with the prefix "pthread_spin_"
in my program */
#else
/* This platform does not support the optional extensions to POSIX and
ISO C standards */
#endif
You can answer a lot of questions like this for yourself by looking at
the contents of <unistd.h> and the contents of this table:
<http://www.unix.org/version3/inttables.pdf>
The second column, "POSIX Base", indicates 'm' for mandatory, or an
option group code (or codes) which must be claimed to be supported by
the contents of <unistd.h> before you are permitted to use the APIs
safely.
As of MacOS 10.4 (or recent XCode releases installed on earlier
versions), the contents of <unistd.h> document the manifest constants
that guard various APIs, and a comment at the end of the line
indicates the option group; so as long as you are looking at a recent
version of MacOS X, you will have all the information needed to decide
whether or not a given API is supported. If you have to run on 10.3
instead of upgrading, then you need to look at the 10.4 <unistd.h> at
the same time, and manually cross-reference to get the option group
references for 10.3.
Whether they are available for kernel mode or user mode.
If they existed, the would only be available for user mode, and with
good reason. Locking is actually not a good way to synchronize kernel
and user space activity, unless you want you program in user space to
be able to make your machine hang for no apparent reason while
something in user space blocks the kernel from making progress, and
then makes a call that blocks behind the kernel being blocked.
There are other mechanisms documented for synchronization between user
space daemons and kernel extensions; usually, people use either
sockets or Mach messages.
Go to <http://www.developer.apple.com> and search for "boundary
crossings"; the first document you see will contain the information
you need to know in order to implement kernel/user space
synchronization.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden