Date: Mon, 28 Dec 1998 18:47:00 -0500 (EST) From: Alfred Perlstein <bright@hotjobs.com> To: Kelly Yancey <kbyanc@freedomnet.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: pthreads question/problem... Message-ID: <Pine.BSF.4.05.9812281837110.2148-100000@bright.fx.genx.net> In-Reply-To: <36881234.BA26320D@freedomnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Dec 1998, Kelly Yancey 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? i think creation != locking but i'm unsure. > > 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. why not cycle through several queues instead of scanning? :) scanning every time isn't efficient, by having 4 queues and rotating it may work better, when filling out the worker-thread's struct be sure to tell it which queue to return itself to :) you'll probably get much more concurancy that way. another advantage of queues is that inserting at the head/removing at the head is fast, and you have a better chance of getting the same threads to run again, this increases the chances of thread specific data being cached. by scanning, you waste cycles scanning doing trylock()'s and destroy thread specific cache. > 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 :) wasn't a simple question, pthreads aren't exactly always intuative. you may want to get O'rielly's(sp?) book on pthreads, although i'm unsure about how detailed it is, or perhaps try to locate the POSIX spec. one more thing, a dirty secret in FreeBSD is that all threads are done as ONE process, if you have multiple CPUs you do not gain the advantage of multiple processors, you have to design a hybrid fork/thread model. enjoy, -Alfred > > 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?Pine.BSF.4.05.9812281837110.2148-100000>