Re: Robust mutexes implementation

>>>>> On Thu, 5 May 2016 21:58:10 +0300, Konstantin Belousov said:
> 
> Yes.  In fact I wrote the __containerof stuff only later, initial
> version of the patch did relied on the fact that m_lock is at the
> beginning of pthread_mutex.
> 
> I rewrote the code in enqueue, and there is one more similar check in
> dequeue_mutex().
> 
> Updated patch is at https://kib.kiev.ua/kib/pshared/robust.2.patch .

OK.


> On Thu, May 05, 2016 at 06:20:35PM +0100, Martin Simmons wrote:
> > Also, is it safe to assume memory ordering between the assignments of
> > m->m_lock.m_rb_lnk and curthread->robust_list?  Maybe it is OK because the
> > kernel will never read curthread->robust_list until after the CPU executing
> > enqueue_mutex has passed a memory barrier?
> 
> Inter-CPU ordering (I suppose you mean this, because you mention
> barriers) only matter when we consider multi-threaded interaction.
> In case of dequeue_mutex, paired to corresponding enqueue_mutex(),
> the calls occur in the same thread, and the thread is always
> self-consistent.

Agreed.


> WRT possible reordering, we in fact only care that enqueue writes do
> not become visible before lock is obtained, and dequeue must finish
> for external observers before lock is released.  This is ensured by
> the umutex lock semantic, which has neccessary acquire barrier on
> lock and release barrier on unlock.

I meant the case where CPU 1 claims the lock, executing this from
enqueue_mutex:

m->m_lock.m_rb_lnk = 0;           /* A */
*rl = (uintptr_t)&m->m_lock;      /* B */

and then the thread dies and CPU 2 cleans up the dead thread executing this
from umtx_handle_rb:

error = copyin((void *)rbp, &m, sizeof(m));     /* C */
*rb_list = m.m_rb_lnk;                          /* D */

where rbp is the value stored into *rl at B by CPU 1.

What ensures that CPU 1's store at A is seen by CPU 2 when it reads the value
at D?  I'm hoping this is covered by something that I don't understand, but I
was worried by the comment "consistent even in the case of thread termination
at arbitrary moment" above enqueue_mutex.

__Martin
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-threads
To unsubscribe, send any mail to "[email protected]"