From owner-freebsd-hackers Wed Sep 5 15:15:11 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by hub.freebsd.org (Postfix) with ESMTP id D1C7937B403; Wed, 5 Sep 2001 15:15:07 -0700 (PDT) Received: from laptop.baldwin.cx (john@[147.11.46.201]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA25669; Wed, 5 Sep 2001 15:15:07 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 05 Sep 2001 15:15:03 -0700 (PDT) From: John Baldwin To: John Baldwin Subject: Re: Posix Threading Cc: Ullasan_Kottummal@kindlebanksys.com, freebsd-hackers@FreeBSD.org, Terry Lambert Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [ I really hate it when my window manager gets stuck in a loop spinning while I'm composing a mail message and I forget to fix up the mail message. *sigh* ] > 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. >> >> -- >> >> 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). Most of what you say is ok, but this is wrong. condition variables do not mandate using a wakeup all strategy. There is such a thing as 'signal' instead of 'broadcast', which only wakes up one thread. PTHREAD_COND_SIGNAL(3) FreeBSD Library Functions Manual PTHREAD_COND_SIGNAL(3) SYNOPSIS #include int pthread_cond_signal(pthread_cond_t *cond); DESCRIPTION The pthread_cond_signal() function unblocks one thread waiting for the condition variable cond. -- John Baldwin -- 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