From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Cc: dbailey27@ameritech.net Subject: Re: [9fans] Re: Threads: Sewing badges of honor onto a Kernel Message-ID: <20040227101110.E24932@cackle.proxima.alt.za> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from Linus Torvalds on Fri, Feb 27, 2004 at 12:08:38AM -0800 Date: Fri, 27 Feb 2004 10:11:10 +0200 Topicbox-Message-UUID: fde6201c-eacc-11e9-9e20-41e7f4b1d025 On Fri, Feb 27, 2004 at 12:08:38AM -0800, Linus Torvalds wrote: > > On Fri, 27 Feb 2004 dbailey27@ameritech.net wrote: > > > > > The rationale is that it's incredibly more sane, and it's the logical > > > place to put something that (a) needs to be allocated thread-specific and > > > (b) doesn't need any special allocator. > > > > You've just proven my point. Thread specific. Being Thread specific, it > > is data that is reserved to the scope of a single thread. Nothing more. > > If you want more scope there are many more usages of memory that > > are better utilized. > > NO! > > A "per-thread allocation" does NOT MEAN that other threads should not > access it. It measn that the ALLOCATION is thread-private, not that the > USE is thread-private. > Wait a minute! If the stack is not thread private, what is? I think this answers my question: stack duplication allows per-thread private space, whereas stack sharing doesn't. This is a one-way path. Unless you drop into register access, where it's the platform that decides whether registers are duplicated or not. But maybe they should also be shared, to be totally consistent. Of course, I may be talking out of turn, but I really don't see how threads can have private space if the stack isn't private. ++L