[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 05 Aug 2014 00:16:58 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: C threads, v3.0
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.
> 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.
> > 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).
> However there's also another BIG use case that's not obsolete:
> POSIX/C11 TSD keys are the only way to store thread-local data that
> needs a destructor to be called when the thread exits.
sure
> 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.
> > 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.
Jens
--
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
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.
