Prev: book
Next: Does "df" modify the ext2 filesystem
From: Ersek, Laszlo on 20 Apr 2010 08:52 On Tue, 20 Apr 2010, Mark Hobley wrote: > In comp.unix.programmer Ersek, Laszlo <lacos(a)caesar.elte.hu> wrote: > >> 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? > > 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. 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
From: Ersek, Laszlo on 20 Apr 2010 15:04 On Tue, 20 Apr 2010, Mark Hobley wrote: > 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
From: Ersek, Laszlo on 19 Apr 2010 19:06 On Mon, 19 Apr 2010, Mark Hobley wrote: > 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
From: Mark Hobley on 19 Apr 2010 20:00 In comp.unix.programmer Ersek, Laszlo <lacos(a)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. Mark. -- Mark Hobley Linux User: #370818 http://markhobley.yi.org/
From: Ian Collins on 19 Apr 2010 20:24
On 04/20/10 12:00 PM, Mark Hobley wrote: > In comp.unix.programmer Ersek, Laszlo<lacos(a)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 |