Date: Wed, 05 Sep 2001 12:40:49 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Ullasan_Kottummal@kindlebanksys.com Cc: freebsd-hackers@FreeBSD.org Subject: Re: Posix Threading Message-ID: <3B967FC1.AEB592D9@mindspring.com> References: <80256ABE.005390D9.00@smtp.kindlebanksys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ullasan_Kottummal@kindlebanksys.com wrote:
>
> Hi All,
> I am trying to create threads under HP-UX 11 using POSIX threads library and
> using the method pthread_create(...).
>
> But I don't know how can I create a thread in a suspended state.
First the obligatory "off topic" humor:
This is not the place to ask about HP-UX programming; you
probably want the Hewlet-Compaqard user's mailing list... 8-p.
--
You don't give us enough information about your application
for us to tell you the correct approach to building it; you've
started with a hammer ("initially suspended threads") and are
ignoring other tools (e.g. "the jaws of life") in your search
for a way to instance your hammer, under the theory that your
problem is a nail (it might not be; you've given us no way to
know).
Probably switching to FreeBSD and the kqueue interface would
better match your problem.
Let's do some setup, and then guess at what you wanted to do,
and give you several approaches to our satisfying our guesses...
Short answer: You can't. The "suspended" state is an attribute
of the thread that is controlled by the threads scheduler, and
is not directly controllable by you.
A thread is guaranteed to be suspended only when it is waiting
on a mutex, condition variable, or blocking call (such as I/O).
I suggest you rethink your design.
If the intent is to get an immediate context switch back to
yourself, you will need to create a mutex that can not be
acquired by the newly created thread, and attempt to acquire
it as the first thing you do.
You can then immediately release it so as not to block other
threads trying the same dirty trick. Note that there is not
an explicit "yield", so you will have to do something like
this to get a "yield" equivalent.
Alternately, if the intent is to create threads so that they
will be around when you need them, you would be better off
delaying their creation until you need them. The expensive
part of threads creation is _supposed_ to be the allocation
of the stack; so if you keep a pool of preallocated stacks
lying around for your use, you will get only a small startup
latency.
If the intent is to have "a pool of idle threads", ready to
go when you get request traffic, and get around the latency,
well, you'd do a lot better in the latency department if you
went to a finite state automaton, instead of messing with
threads. But if you insist, the best you are going to be
able to get is use of a mutex, since a condition variable will
result in a "thundering herd" problem. You will still have to
eat the latency for the mutex trigger to the thread you give
the work to, however (this is how I designed the work-to-do
dispatcher in the Pathworks for VMS (NetWare) product for DEC
and Novell).
If the intent is a "horse race", where you create a bunch of
threads, and then open the "starting gate" and have them all
start going ``at once'', then you want a condition variable. I
intentionally quoted ``at once'', since the concurrency will
not be real without multiple CPUs and cooperation from the OS,
it will be virtual -- just as if you were running multiple
processes, instead of trying to use threads. This is an
artifact of the scheduler, and varies from implementation to
implementation.
Note: I don't know what level of standards compliance the
HP-UX 11 version of pthreads has achieved; some of the things
described above are probably not going to be easy to achieve
in downrev versions of the library. Last time I looked, the
HP-UX version of pthreads was a Draft-4 version, not a Draft-10
or standard version, so you may be in more trouble than you
originally thought; specifically, you will have a problem with
creating a preinitialized mutex in a Draft-4 version of pthreads,
so you will have to create the mutex (if you use one) first.
-- Terry
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?3B967FC1.AEB592D9>