Date: Mon, 28 Dec 1998 18:20:20 -0500 From: Kelly Yancey <kbyanc@freedomnet.com> To: Alfred Perlstein <bright@hotjobs.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pthreads question/problem... Message-ID: <36881234.BA26320D@freedomnet.com> References: <Pine.BSF.4.05.9812281801000.2148-100000@bright.fx.genx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote:
>
> this was discussed a while back, i think the concensus was that it is a
> programming error for a thread to unlock a mutex that it, itself did not
> lock.
But it is still OK for other threads to call trylock() on a mutex
another thread created?
>
> you will have to find another way to handle this :)
I see what you mean, perhaps just one mutex for access to the entire
pool which the main thread (or perhaps several threads) can contend for
and manage (ie. lock/unlock). It could wait on the lock, add the new
request, signal the conditional variable, and then release the lock. My
only concern had been preventing "worker" threads from accessing data at
the same time as the "server" threads, but they could follow the same
series of lock/update/unlock. It seems to me, though, that could reduce
concurrency since I'm preventing any two threads from updating 2
separate data structures at the same time in many cases. Perhaps I'll
still need an array of mutexes, one per request structure.
So it is OK for two separate threads to manipulate the same mutex, so
long as the lock and unlock operations are performed by the same thread.
In other words, I could still use an array of mutexes so long as the
thread which locks the mutex is the same as the thread which unlocks it.
That seems workable.
>
> what you may want to do is wrap a queue of thread IDs with mutexes,
> when the main thread wants to dispatch to a worker thread it:
>
> a locks the queue on the mutex
> b removes an entry
> c dispatches that thread
> d unlocks the queue
>
> (note that 'c' and 'd' can be swapped)
>
> when a worker thread is done it:
> a locks the queue
> b adds itself to the queue
> c unlocks the queue
>
> how does that sound? (you also don't have to scan an array of mutexes :)
Sounds good :) Sorry...I should have read before I typed. But I think
I'll stick to an array rather than a queue (I need the efficiency in the
final program) and stick to an array of mutexes for increased
concurrency.
Wow, thanks for all the help. Perhaps one day people like me won't
have to ask such simple questions...perhaps one day there will be more
information on pthreads programming (maybe even specifically for
FreeBSD), or at least more informative man pages :)
Thanks again,
Kelly
--
Kelly Yancey "Bill Gates is only a white Persian cat and
~kbyanc@freedomnet.com~ a monocle away from being the villain in a
James Bond movie" - comedian Dennis Miller
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36881234.BA26320D>