Date: Wed, 05 Sep 2001 14:47:24 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-hackers@FreeBSD.org, Ullasan_Kottummal@kindlebanksys.com Subject: Re: Posix Threading Message-ID: <XFMail.010905144724.jhb@FreeBSD.org> In-Reply-To: <3B967FC1.AEB592D9@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05-Sep-01 Terry Lambert wrote:
> 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
--
John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
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?XFMail.010905144724.jhb>