This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Synchronizing auxiliary mutex data
On Jun 20 2017, Alexander Monakov <amonakov@ispras.ru> wrote:
> Plain accesses to fields like __data.owner are fine as long as they all are
> within critical sections set up by LLL_MUTEX_{LOCK,UNLOCK}, but there are some
> outside of them. So e.g. in nptl/pthread_mutex_lock:
>
> 95 else if (__builtin_expect (PTHREAD_MUTEX_TYPE (mutex)
> 96 == PTHREAD_MUTEX_RECURSIVE_NP, 1))
> 97 {
> 98 /* Recursive mutex. */
> 99 pid_t id = THREAD_GETMEM (THREAD_SELF, tid);
> 100
> 101 /* Check whether we already hold the mutex. */
> 102 if (mutex->__data.__owner == id)
> 103 {
> 104 /* Just bump the counter. */
> 105 if (__glibc_unlikely (mutex->__data.__count + 1 == 0))
> 106 /* Overflow of the counter. */
> 107 return EAGAIN;
> 108
> 109 ++mutex->__data.__count;
> 110
> 111 return 0;
> 112 }
> 113
> 114 /* We have to get the mutex. */
> 115 LLL_MUTEX_LOCK (mutex);
> 116
> 117 assert (mutex->__data.__owner == 0);
What keeps the cpu from using its cached value of __owner here?
> afaict the access at line 102 can invoke undefined behavior due to a data race.
Is that the undefined behaviour here?
> In practice I think it works fine because the compiler doesn't tear the load,
What does "tear the load" mean?
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."