Re: PR/57437 CVS commit: src/lib/libpthread

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

The following reply was made to PR port-arm/57437; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Vasily Dybala <Vasily.Dybala%kaspersky.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost,
	port-arm-maintainer%netbsd.org@localhost,
	gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: PR/57437 CVS commit: src/lib/libpthread
Date: Fri, 26 May 2023 10:29:54 +0000

 > Date: Fri, 26 May 2023 08:03:18 +0000
 > From: Vasily Dybala <Vasily.Dybala%kaspersky.com@localhost>
 > 
 > Fix looks ok, but pthread__smt_wake() call from
 > pthread_mutex_unlock() will call SEV instruction which does not have
 > paired WFE in pthread_mutex_lock().
 
 We could add a call to pthread__smt_wake in pthread_mutex_unlock to
 match a pthread__smt_wait in pthread__mutex_pause, but that's not
 enough on its own, because currently pthread__mutex_spin calls
 pthread__mutex_pause in a loop and might just WFE again without
 realizing it can make progress after it has been woken by SEV.
 
 So we would need to restructure pthread__mutex_spin so that it calls
 pthread__smt_wait exactly once after it examines the owner and
 determines the owner is still running on a CPU.
 
 That may be worthwhile, but it's a little more involved to implement,
 because the surrounding logic has to be conditionalized on which style
 of spin loop.  So I picked the less-risky and less-involved option to
 commit now.  We can try the WFE/SEV approach for pthread_mutex (and
 rwlock and, if it's still relevant, simple lock) later.
 
 > I will check patch during next week.
 
 Great, thanks!