From owner-freebsd-hackers Sat Feb 15 17:05:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA00400 for hackers-outgoing; Sat, 15 Feb 1997 17:05:12 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA00393 for ; Sat, 15 Feb 1997 17:05:05 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA06525; Sat, 15 Feb 1997 18:03:42 -0700 From: Terry Lambert Message-Id: <199702160103.SAA06525@phaeton.artisoft.com> Subject: Re: Threads question To: jehamby@lightside.com (Jake Hamby) Date: Sat, 15 Feb 1997 18:03:42 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: <199702152346.PAA05346@lightside.com> from "Jake Hamby" at Feb 15, 97 03:46:45 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Although I'd like to use POSIX threads for the greater portability, > apparently POSIX doesn't offer the option to suspend and resume threads, so > I've decided to use Solaris threads. > > Anyway, just wanted to solicit any advice on the best thread library to use > for a FreeBSD (or Linux) port of my toolkit, when it is finished. I've > decided to start with a Solaris version, simply because I have access to it > (on SPARC and x86), and it has VERY good documentation on the thread > functions supported, the differences between Solaris and POSIX threads, and > the thread-safeness of each library function. IMHO, this is one area where > FreeBSD is very weak. Comments? libc_r (r == reentrant) is thread-safe. The "suspend" and "resume" is a non-sequitur. It refers to the ability to control scheduling in a preeemptive scheduling environment. Pthreads is thread-safe. The "suspend" and "resume" is a non-sequitur. It refers to the ability to control scheduling in a preeemptive thread scheduling environment. Pthreads is a non-preemptive thread scheduler, performindg a thread context switch when a blocking call would occur, by calling a non-blocking call instead, and performing a context switch (implementation is not exact, but this is the net effect). What you are asking for is the ability to "suspend" a thread that is already "suspended"... and resume means "give away my processor to this other thread" -- "yield". If you want to have fine grain control over whether a thread is actually scheduled to run once it is on the ready-to-run queue in the user space scheduler, the modifications to the pthreads code would be trivial. In general, you can achive this same type of lock-step synchronization using semaphores, however, so there's no reason to mix the two control models. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.