[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: pthreads question/problem...
From:       Kelly Yancey <kbyanc () freedomnet ! com>
Date:       1998-12-28 23:51:20
[Download RAW message or body]



Alfred Perlstein wrote:
> 
> On Mon, 28 Dec 1998, Kelly Yancey wrote:
> 
> 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.

  Ahh, good idea. Thanks.

> 
> 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.

  I had completely forgotten about caching data. It is amazing how the
mind rots after years of being away from assembler :)

> 
> 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.

  I think I looked at O'Reilly's book (I've looked at a few now). Oddly,
I seem to recall it being somewhat useless. Perhaps I'm thinking of one
of the other books...I'll have to go double check...O'Reilly typically
produces good books. I'de love to get my hands on the Posix spec, but I
was under the impression that since it is being produced via ISO that it
costs $$$ to get the spec (would seem kind of contradictory to the point
of publishing a spec though, wouldn't it? :) )

> 
> 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.
> 

  Argh. Is this going to be fixed in 3.0? Does anyone intend on fixing
it? I mean, even Linux has kernel support for threads, I should think
that FreeBSD...the king of server OS'es...could at least do the same.
For the time being this isn't a problem, as I only have a single CPU,
but I'm really going to need FreeBSD to support scheduling threads on
separate processors by the time I finish the project. I *really* like
FreeBSD, but if I have to I suppose Linux will be the target platform if
3.0 can't schedule threads independantly.

  You've been a great help,

  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

[prev in list] [next in list] [prev in thread] [next in thread]