Prev: chroot() and popen() won't get along
Next: Memory eating...
From: Rick Jones on 15 Apr 2010 18:41
> > struct buffer {
> > char *addr;
> > unsigned int sz;
> > unsigned int ptr;
> > unsigned int tail;
> > pthread_mutex_t buffermx;<--- Can I put the mutex here?
> > };

> Sure. Good place for it, I'd say.

Depends - how many struct buffers will there be and how many will be
"active" at one time? It could make more sense to hash the
structure's address into a table of mutexes - more than one struct
buffer would be "protected" by a given mutex, but if there are lots
and lots and lots of struct buffers it might save a great deal of
memory.

Personally, if embedding I'd be inclined to put the mutex at the
beginning of the structure, on the premis that it has the most
stringent alignment requirements and I like to avoid "holes" in data
structures.

rick jones
--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
- Rick Jones
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: Rick Jones on 15 Apr 2010 18:53
In comp.unix.programmer Eric Sosman <esosman(a)ieee-dot-org.invalid> wrote:
> To make it work, you would need to do something awful like

> - make sure all the mutexes in the region are unlocked, and
> that no other thread will try to lock any of them,

That implies a higher-level lock yes? Perhaps a global read-write
lock where normally a read lock is taken, but when one wants to mess
with the structures one grabs the read/write as a write.

BTW, for the OP - something similar would be required if one used a
hash table of mutexes - in that case though you would walk through the
hash table locking all the mutexes, then you can realloc the
structure(s) protected by those mutexes, then you can unlock all the
mutexes and let the other threads do their thing. Or you could nest
under a read/write lock - but it means having a read/write lock's
pathlength added to each access.

rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: Barry Margolin on 15 Apr 2010 21:54
In article <82pg9eFdqgU1(a)mid.uni-berlin.de>,
jt(a)toerring.de (Jens Thoms Toerring) wrote:

> In comp.unix.programmer Mark Hobley <markhobley(a)hotpop.donottypethisbit.com>
> wrote:
> > I have some data structures that I want to protect using a mutex for the
> > purpose of making thread safe code.
>
> > Is it ok, to include the mutex datatype within the data structure that I
> > wish
> > to protect? For example:
>
> > struct buffertable {
> > struct buffer *addr;
> > int sz;
> > unsigned int currentdefault;
> > unsigned int chunksize;
> > unsigned int tablechunk;
> > pthread_mutex_t buffertablemx; <--- Can I put the mutex here?
> > };
>
> That's completely legal. 'pthread_mutex_t' is just another type,
> just with a fancy name. You can put basically everything into a
> structure that the compiler can figure out how much space (and
> what alignment) it needs.
>
> > extern struct buffertable buffertable;
>
> > In the above case I want to protect the values of the buffertable using the
> > buffertablemx mutex.
>
> > Can I also protect dynamically created structured arrays by having a mutex
> > as part of the array definition?
>
> > struct buffer {
> > char *addr;
> > unsigned int sz;
> > unsigned int ptr;
> > unsigned int tail;
> > pthread_mutex_t buffermx; <--- Can I put the mutex here?
> > };
>
> > buffertable.addr = malloc(tablesize * sizeof(struct buffer));
> > ^
> > |
> > I plan to have a mutex for dynamically allocated structures. This
> > will enable me to apply a mutex to just one particular element of
> > the array without affecting other elements. In this case, it is
> > convenient to be able to bundle the mutex record in with the data
> > structure, because sometimes the tablesize will be increased via a
> > realloc call, and this would mean that new mutexes are required to
> > work with the new elements.
>
> Also that is legal - if you can put a 'pthread_mutex_t' in a
> structure you can put it into an array of structures, be it
> allocated statically or dynamically.
>
> What I don't like is your lying to the compiler about the type
> the 'addr' member is obviously going to point to. What keeps
> you from using the real type, i.e 'struct buffer *', as the
> type of the 'addr' member? Using a 'char *' (or 'void *' which
> would look a bit more natural since at least shows it's not
> about a char array but some opaque data type) only will force
> you to use ugly casts all over the place. It's completely ok
> to write

What makes you think that buffer::addr points to a struct buffer and not
a character string? This is an array element, why do you think it's an
element of a linked list?

--
Barry Margolin, barmar(a)alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
From: Mark Hobley on 16 Apr 2010 02:35
In comp.os.linux.development.apps Eric Sosman <esosman(a)ieee-dot-org.invalid> wrote:

> So: If you must move your data structures around in memory,
> don't put mutexes (or semaphores, or condition variables) in them
> even though that would ordinarily be a good spot. Personally, I'd
> take a second look at why you want to move things around; maybe
> it's not really necessary.

I am writing a library to handle dynamic buffers. The initializer provides a
dynamic table that can track a default number of buffers. In most cases this
will be sufficient. However, in some cases, it may be that an application
requests more buffers than the table will hold. In this case, the library will
resize the table (using realloc) and add an additional number of entries to
satisfy the demand for extra buffers.

http://markhobley.yi.org/mlibrary/libbuffers/index.html

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

From: Jens Thoms Toerring on 16 Apr 2010 03:49
In comp.unix.programmer Barry Margolin <barmar(a)alum.mit.edu> wrote:
> In article <82pg9eFdqgU1(a)mid.uni-berlin.de>,
> jt(a)toerring.de (Jens Thoms Toerring) wrote:

> > In comp.unix.programmer Mark Hobley <markhobley(a)hotpop.donottypethisbit.com>
> > wrote:
> > > buffertable.addr = malloc(tablesize * sizeof(struct buffer));
> >
> > What I don't like is your lying to the compiler about the type
> > the 'addr' member is obviously going to point to. What keeps
> > you from using the real type, i.e 'struct buffer *', as the
> > type of the 'addr' member? Using a 'char *' (or 'void *' which
> > would look a bit more natural since at least shows it's not
> > about a char array but some opaque data type) only will force
> > you to use ugly casts all over the place. It's completely ok
> > to write

> What makes you think that buffer::addr points to a struct buffer and not
> a character string? This is an array element, why do you think it's an
> element of a linked list?

My impression isn't that 'addr' is meant as part of a linked list
but as a pointer to an array of structures - the way the alloca-
tion is done would seem to me to be very strange if really meant
for an array of chars as the type of 'addr' (char *) is expres-
sing. What would one do with a char array of a length that's a
multiple of the length of a structure, given that the amount of
memory allocated can depend on the compiler and the system being
used? But, of course, I could be wrong and there's some hiddens
sense behind this I am not discerning.

Regards, Jens
--
\ Jens Thoms Toerring ___ jt(a)toerring.de
\__________________________ http://toerring.de
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: chroot() and popen() won't get along
Next: Memory eating...