pthread_mutex_t and pthread_rwlock_t
Mark Hobley
define a mutex or an rwlock with a default value by providing a value of NULL
to the appropriate initialization functions:
pthread_mutex_init(mymutex,NULL);
pthread_rwlock_init(myrwlock,NULL);
However, the documentation that I have found so far seems to be vague about
what attributes are and what values are available.
What are these attributes? I know (or I think I know) that the mutex and
rwlock mechanisms utilize these attributes during operation.
What values other than NULL could I have provided? Is the intent of these
functions to allow users to specify their own attribute properties or are
attributes just set to either NULL, or copied from other mutexes and rwlocks?
Mark.
--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/
Ersek, Laszlo
> What are these attributes? I know (or I think I know) that the mutex and
> rwlock mechanisms utilize these attributes during operation.
Open [0] in your browser and search for these strings:
- pthread_mutexattr_
- pthread_rwlockattr_
Cheers,
lacos
[0] http://www.opengroup.org/onlinepubs/9699919799/basedefs/pthread.h.html
Mark Hobley
> Open [0] in your browser and search for these strings:
> - pthread_mutexattr_
> - pthread_rwlockattr_
Hmmm. Thanks for that. Unfortunately that is a really horrible set of
documents to work with. I can't immediately spot the answer from that.
It is 1 oclock in the morning here at the moment, and I will get a real
headache trying to dissect that lot now, so I'll try and do some reading and
rereading over the next few days and see if I can make any sense of it.
Ian Collins
> In comp.unix.programmer Ersek, Laszlo<la...@caesar.elte.hu> wrote:
>
>> Open [0] in your browser and search for these strings:
>> - pthread_mutexattr_
>> - pthread_rwlockattr_
>
> Hmmm. Thanks for that. Unfortunately that is a really horrible set of
> documents to work with. I can't immediately spot the answer from that.
> It is 1 oclock in the morning here at the moment, and I will get a real
> headache trying to dissect that lot now, so I'll try and do some reading and
> rereading over the next few days and see if I can make any sense of it.
A key phrase you will find is:
"The pthread_attr_init() function shall initialize a thread attributes
object attr with the default value for all of the individual attributes
used by a given implementation."
So you have to go to your implementation's documentation to find the
default values. Try man pthread_attr_init.
--
Ian Collins
Ersek, Laszlo
> In comp.unix.programmer Ersek, Laszlo <la...@caesar.elte.hu> wrote:
>
>> Open [0] in your browser and search for these strings:
>> - pthread_mutexattr_
>> - pthread_rwlockattr_
>
> Hmmm. Thanks for that. Unfortunately that is a really horrible set of
> documents to work with.
I'll pretend I didn't hear that. That set of documents *defines* UNIX(R).
> I can't immediately spot the answer from that.
Umm, press Ctrl-G in Firefox a few times, and when you hit clickable links
in the SEE ALSO section, leverage the middle button (or Shift-F10 + "t")
repeatedly to facilitate a breadth-first traversal of individual attribute
specifications. Is that too much work?
Cheers,
lacos
:P
Ersek, Laszlo
> "The pthread_attr_init() function shall initialize a thread attributes
> object attr with the default value for all of the individual attributes
> used by a given implementation."
>
> So you have to go to your implementation's documentation to find the
> default values. Try man pthread_attr_init.
Hmm, pthread_attr_getdetachstate() says, "The default value of the
detachstate attribute shall be PTHREAD_CREATE_JOINABLE." I don't think
this is implementation-dependent (or rather, I hope very much it is not).
pthread_attr_getstacksize() is probably different.
Cheers,
lacos
Ian Collins
I think you just answered your own question, some are system specific,
others not. So he may as well check his man pages!
--
Ian Collins
Mark Hobley
Well. I did that. I found some notes on a thing called "type attributes", but
I notice that these are of type int, whereas the attributes that I am talking
about are of types pthread_mutexattr_t and pthread_rwattr_t, so I am currently
confused. Are these talking about the same things? What the document talks
about a "type attribute", does it mean an "attribute"? If so, why is there
a difference in the typecast?
Mark Hobley
> So you have to go to your implementation's documentation to find the
> default values. Try man pthread_attr_init.
Right. That man page does not appear on my system (based on Debian). I'll find
out which package that is hidden in, and try and get the missing page
installed.
Cheers,
Bill Cunningham
> I am writing code that utilizes mutexes and rwlocks. I know that I can
> define a mutex or an rwlock with a default value by providing a value
> of NULL to the appropriate initialization functions:
There is comp.programing.threads
Bill
Rainer Weikusat
> In comp.unix.programmer Ian Collins <ian-...@hotmail.com> wrote:
>> So you have to go to your implementation's documentation to find the
>> default values. Try man pthread_attr_init.
>
> Right. That man page does not appear on my system (based on Debian). I'll find
> out which package that is hidden in, and try and get the missing page
> installed.
It might be a better idea to have a look at the glibc
documentation. The GNU-project doesn't use the tradtional UNIX(*) text
formatting engine to create documentation but a set of TeX-macros
('texinfo') which can be used to either create hypertext-documents
suitable for online reading (this was invented way before the WWW) or
printed books. You can access the manual with the command
info libc
(if you have the glibc-doc-reference [non-free] package installed).
NB: At least by default, this program uses Emacs-keybindings and not
vi-keybindings and the search-function is invoked by 's' and not '/'.
Thread attributes are described in section 34.2.
Ersek, Laszlo
Oh come on. I give up. (I'm not angry at you, I'm just generally angry,
but I still want to help.) Here are the links for you:
[0] http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_getprioceiling.html
[1] http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_getprotocol.html
[2] http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_getpshared.html
[3] http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_getrobust.html
[4] http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_gettype.html
[5] http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlockattr_getpshared.html
Look at the NAME section in each page:
- get and set the prioceiling attribute of the mutex attributes object
- get and set the protocol attribute of the mutex attributes object
- get and set the process-shared attribute
- get and set the mutex robust attribute
- get and set the mutex type attribute
- get and set the process-shared attribute of the read-write lock
attributes object
Each "thing" you want to manipulate (thread, mutex, condvar, rwlock) has a
set of attributes. Each SUS seems to add some more in case of each one. So
that it doesn't break previous practice, the set of attributes for each
kind of object was designed from a ground up as an opaque data structure.
As new attributes are added, that's implemented by specifying new setter
and getter functions. The setter/getter functions describe the new
attribute (the new element of the attribute set for a given type of
object, ie. thread attributes, mutex attributes etc), or they refer you to
the description in <pthread.h>. The default value or behavior for each new
attribute appears to be determined in a way that is consistent with the
earlier SUS versions.
For example (warning, superficial speculation follows), the mutex robust
attribute introduced in SUSv4, which seems to retrofit the older semadj /
SEM_UNDO stuff to process shared mutexes, has PTHREAD_MUTEX_STALLED as
default value.
lacos
Ersek, Laszlo
> Right. Having looked at those, I think the answer is as follows:
>
> The value of the attribute passed to pthread_mutex_init and
> thread_rwlock_init can be either NULL, or the address of a separate
> attribute object, which is created by pthread_mutex_attrinit or
> pthread_rwlock_attrinit.
Rather "prepared for use" than "created", because "creation" would
probably entail allocation as well; but otherwise, okay. (I'm avoiding the
overloaded word "initialization", because you don't initialize the
attribute object in the C sense. (Or if it has static storage duration,
you don't explicitly initialize it in the C sense.))
> If I want to set attributes, I would first call pthread_mutex_attrinit
> or pthread_rwlock_attrinit to create the attribute object. Then I would
> call a load of "setter" functions to set the porperties of the attribute
> object that I had created, depending on the attributes that I wished to
> set. Finally, I would call pthread_mutex_init or pthread_rwlock_init to
> create the mutex or rwlock with the address of the attribute object. If
> I wanted several mutexes or rwlocks with the same attributes, then I
> would pass the same attribute object to each of the mutexes or rwlocks
> that were to have the same attributes.
>
> Does that sound about right?
With the above note on allocation, bullseye.
Cheers,
lacos
Mark Hobley
> There is comp.programing.threads
Oh right. Cheers Bill. I will note that for future reference.
> Bill
Mark Hobley
> Oh come on. I give up. (I'm not angry at you, I'm just generally angry,
> but I still want to help.) Here are the links for you:
>
> [0] http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_getprioceiling.html
> [1] http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_getprotocol.html
> [2] http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_getpshared.html
> [3] http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_getrobust.html
> [4] http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_gettype.html
> [5] http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlockattr_getpshared.html
>
> Look at the NAME section in each page:
>
> - get and set the prioceiling attribute of the mutex attributes object
> - get and set the protocol attribute of the mutex attributes object
> - get and set the process-shared attribute
> - get and set the mutex robust attribute
> - get and set the mutex type attribute
> - get and set the process-shared attribute of the read-write lock
> attributes object
Right. Having looked at those, I think the answer is as follows:
The value of the attribute passed to pthread_mutex_init and
thread_rwlock_init can be either NULL, or the address of a separate attribute
object, which is created by pthread_mutex_attrinit or pthread_rwlock_attrinit.
If I want to set attributes, I would first call pthread_mutex_attrinit or
pthread_rwlock_attrinit to create the attribute object. Then I would call a
load of "setter" functions to set the porperties of the attribute object that
I had created, depending on the attributes that I wished to set. Finally, I
would call pthread_mutex_init or pthread_rwlock_init to create the mutex or
rwlock with the address of the attribute object. If I wanted several mutexes
or rwlocks with the same attributes, then I would pass the same attribute
object to each of the mutexes or rwlocks that were to have the same attributes.
Does that sound about right?
Mark.
David Schwartz
Hobley) wrote:
> Well. I did that. I found some notes on a thing called "type attributes", but
> I notice that these are of type int, whereas the attributes that I am talking
> about are of types pthread_mutexattr_t and pthread_rwattr_t, so I am currently
> confused. Are these talking about the same things? What the document talks
> about a "type attribute", does it mean an "attribute"? If so, why is there
> a difference in the typecast?
It's hard to answer without knowing what you're looking at. The
attributes that are bundled into a pthread_mutex_t or a
pthread_rwlock_t don't have any particular type. For example, one
attribute is whether the mutex is process shared or not. While you
could think of that as a boolean, there is no case where you would
actually have the value of that attribute stored in a boolean -- it's
somehow bundled with all the other attributes into the pthread_mutex_t
in an implementation-specific way.
DS