Date: Mon, 4 Aug 2014 18:36:57 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: C threads, v3.0 On Tue, Aug 05, 2014 at 12:16:58AM +0200, Jens Gustedt wrote: > Am Montag, den 04.08.2014, 13:06 -0400 schrieb Rich Felker: > > On Mon, Aug 04, 2014 at 06:48:59PM +0200, Jens Gustedt wrote: > > > Am Montag, den 04.08.2014, 10:50 -0400 schrieb Rich Felker: > > > > On Mon, Aug 04, 2014 at 11:30:03AM +0200, Jens Gustedt wrote: > > > > > I'd like to discuss two issues before going further. The first is of > > > > > minor concern. In many places of that code _m_lock uses a flag, namely > > > > > 0x40000000. I only found places where this bit is read, but not where > > > > > it is set. Did I overlook something or is this a leftover? > > > > > > > > It's set by the kernel when a thread dies while owning a robust mutex.. > > > > > > ah, ok, good to know, this was not obvious at all to me. > > > > > > so I will leave this in, although C mutexes are not supposed to be > > > robust. > > > > If the C committee decides that the case of exiting with a mutex > > locked needs to be handled (i.e. the mutex must be permanently locked, > > not falsely owned by a new thread that happens to get the same id) > > then we need to track such mutexes in the robust list. > > I think it is very unlikely that such a decision would be taken. This > stuff is supposed to run on about any OS, not only POSIX. Imposing > such restrictions to other OS' is unlikely to happen. For the same > reason there is strong resistance against static initialization of > mutexes, e.g., simply because one well-known OS seems not to be able > to deal with it. I'm less confident. In principle any OS can have each thread put the mutexes it holds in a linked list and mark them all permanently-locked when the thread exits. Robust mutexes are hard on POSIX only because they have to support process-shared semantics where a process can be killed asynchronously by an uncatchable signal. > > Technically we > > wouldn't have to rely on the kernel to do anything with them (that > > only matters for process-shared case; for process-local, we control > > thread exit and can handle them ourselves) but letting the kernel do > > it does reduce the amount of code in pthread_exit, so it might be > > desirable still. > > ok, we definitively should leave it in, then. I haven't reviewed the actual code yet but I'll take a look and see if it looks like it would work. Actually making recursive and error-checking POSIX mutexes "always robust" (not exactly, but that's roughly how it would work) is a change I should make soon anyway. And I also have the private-futex patch pending, awaiting evidence that it's actually useful before applying it. > > > As I said, I think this is a feature that is rarely used anyhow. For > > > the code that actually links pthread_key_create, it is not at all > > > clear to me that pthread_setspecific is then used by a lot of > > > threads. I don't have stats for this, obviously, but the tss stuff > > > will even be used less. > > > > It's not that rare, and it's the only way in portable pre-C11 POSIX > > programs to use thread-local storage. Presumably most such programs > > check for the availability of gcc-style __thread and use it if > > possible, only falling back to the old pthread TSD if it's not. > > With C11 threads they are guaranteed to have _Thread_local. So the > check against __thread is then obsolete (and trivial). Yes. That's why I said pre-C11 POSIX programs. > > The only possible interaction we could care about would be if POSIX > > specified that PTHREAD_KEYS_MAX keys must be allocatable even if some > > C11 keys have already been allocated, and/or vice versa. In this case > > we could need to separately track the number of each and allow a > > higher total number. But I don't see how this would otherwise affect > > the requirements on, or implementation of, either one. > > The rules for calling destructors also might differ. For the moment C > is sufficiently vague that almost any strategy would do, but who knows > where this will drift. > > BTW, I think that the current implementation of > __pthread_tsd_run_dtors is not completely in line with the text. As I > understand it, each iteration should just treat the keys in one batch > per iteration. Each batch consisting of those keys that have values at > the beginning of that iteration. But that is hopefully completely > irrelevant in real world. If I'm not mistaken, I think the iterations macro is the minimum number of times a dtor will be called; it seems permissible for the implementation to call it more times. > > > We could implement tss separately. That's quite simple to do. > > > > Yes but that of course increases the cost of a largely-useless (except > > in the case of needing a dtor) feature, especially in per-thread > > memory needed, which I would like to avoid unless it turns out to be > > needed. > > I just implemented it, and if I use either that new implementation or > the one with pthread_key_create underneath, there is a difference of 8 > bytes for the executable. The difference would only appear for an > application that uses both features. OK I'll take a look. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.