This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: TSX lock elision for glibc v12


Carlos asked me to send a more detailed plan for how we could split up
Andi's work so that we can commit the parts that we can (hopefully) get
consensus on before the freeze.  This might have some rough edges, but
should show what I have in mind.  Comments?

1) Give PTHREAD_MUTEX_DEFAULT a new enum value != 0 (and thus not equal
to PTHREAD_MUTEX_NORMAL's value)

TODO (new code):
* New enum.  Mutex type mask is okay?
* Update the default initializers to use the new enum value.
* Bump symbol versions of every function that takes a pthread_mutex_t,
  and settype().
* Handle the new enum in all these functions; just do the same as for
  PTHREAD_MUTEX_NORMAL.

Rationale:
* This allows us to enable elision for DEFAULT mutexes without changing
the semantic guarantees of NORMAL mutexes.
* There is some churn, and we add to the ABI, but this should have
little effect on performance; we already have a few types, one more
shouldn't matter much.
* We don't yet know (AFAIK) whether PTHREAD_MUTEX_TIMED_NP and
PTHREAD_MUTEX_ADAPTIVE_NP are supposed to be like DEFAULT or NORMAL.
Assuming that they are like NORMAL is safe for now, so keep their enum
values unchanged.  This can be easily changed later on if necessary and
possible.


2) Allow for elision in mutexes without changing semantic guarantees.

TODO (can mostly be picked from Andi's patches I guess):
* Pick most of Andi's 9/9 patch, except in elision-conf.c:
  * No need to check __libc_enable_secure; we're not changing semantics.
  * Either use __elision_available and a separate
    __pthread_elision_by_default flag, or just a combined one.  Note
    that this flag does guarantee that POSIX semantics are fulfilled,
    unlike in Andi's current patches.  This flag is controlled by the
    --enable-lock-elision configure switch.
* Pick most of 1/9:
  * Adapt trylock(): remove "upgrade" param, treat it as always nonzero.
  * Adapt elision_init() to get the switch we need.
* Don't pick 2/9.
* Pick some parts of 3/9:
  * Don't pick anything related to the new mutex types or bits.
  * In the branch for default mutexes, use elision if enabled with the
    configure switch.
  * trylock never uses elision.
  * Don't pick PTHREAD_MUTEX_UPGRADED_ELISION_NP.
  * Don't pick force-elision.h. We can just go by the mutex types at
    this stage.  DEFAULT can always use elision, no need to force it,
    and no need for the "upgrade" bit in the mutex type.
  * Only use elision if the flag controlled by the configure switch
    is true.
* Pick+adapt the manual / test changes as appropriate.

Rationale:
* Satisfies Roland's requirements.
* Can be enabled without affecting correctness.


3) Allow for elision in rwlocks without changing semantic guarantees.

TODO Pick parts of 5/9:
* Reuse the config switch from stage 2) or a separate one.
* Don't pick pthreadtypes.h, internaltypes.h, lowlevelrwlock.sym,
  pthread_rwlock_init.c.
* Don't pick any of the wrlock changes.  See the guidelines why this
  would violate POSIX requirements.
* Pick the rdlock changes, but adapt so that they use elision if it is
  available
* Pick+adapt the manual / test changes as appropriate.

Rationale:
* Enables elision for where you really need it: read locks.
* Satisfies Roland's requirements.
* Can be enabled without affecting correctness.


I don't have details for how to split the rest of what Andi proposed.
Those changes don't seem to be likely to find consensus now, so they can
be tackled later on.

Torvald


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]