From owner-freebsd-hackers Mon May 19 09:24:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA00853 for hackers-outgoing; Mon, 19 May 1997 09:24:59 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA00842; Mon, 19 May 1997 09:24:54 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA24243; Mon, 19 May 1997 09:16:25 -0700 From: Terry Lambert Message-Id: <199705191616.JAA24243@phaeton.artisoft.com> Subject: Re: GNAT-pthreads integration bugs/questions To: gibbs@plutotech.com (Justin T. Gibbs) Date: Mon, 19 May 1997 09:16:25 -0700 (MST) Cc: dyson@FreeBSD.ORG, davem@caip.rutgers.edu, terry@lambert.org, deischen@iworks.InterWorks.org, freebsd-hackers@FreeBSD.ORG, jb@freebsd1.cimlogic.com.au In-Reply-To: <199705190441.WAA26421@pluto.plutotech.com> from "Justin T. Gibbs" at May 18, 97 11:39:21 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 > It sounds to me like using the base of the stack would be an excelent > and cheap way to implement the equivelent of NT's "thread local > storage". You'd need toolchain support at the very least with the > program image specifying the amount of stack space to "reserve". "Thread Local Storage" is only useful in a limited range of cases, even (especially?) under NT. There are four threading models under WIN32: 1) Single threaded 2) Rental model threading 3) Apartment model threading 4) Free threading Only cases 2 & 3 have a use for thread local storage. Cases 2 & 3 have the following drawbacks: o CPU starvation sofr some threads in N:M mapping o Not SMP scalable o Not "work to do" model o Require interface marshalling between threads (Actually, free threading requires interface marshalling: see the MSVC++ documentation for CoCreateFreeThreadedMarshaller()... this is because of allocation of interfaces to thread local storage -- a design flaw which they must now live with for all of eternity). There are special circumstances where you might want thread local storage for a free threaded application, ie: for state local to the trasaction, *during* the transaction. But the free threading model does not permit persistant state in thread local storage: that would imply task-binding to a single thread: apartment model threading. In other words, the state in thread local storage would exist only over the life of the transaction, and be destroyed when it comes to its conclusion. An intelligent programmer will use the thread stack for this, instead, and not incur the runtime allocation/deallocation overhead associated with modifying the address space map. Microsoft recommends "free threading"; I happen to agree with them (it's rare, mark it on your calendars). Yes, they screw this up by where their constructors allocate storage for interfaces (using LocalAlloc), but that's *their* screw-up -- not something that a decent implementation would have to live with. All you do with "thread local storage" is enable the creation of crippled programs. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.