This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [PATCH] Optimized __cxa_guard_{acquire,release,abort} for Linux
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Paolo Carlini <pcarlini at suse dot de>, Richard Guenther <richard dot guenther at gmail dot com>, Benjamin Kosnik <bkoz at redhat dot com>, gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Fri, 4 Jan 2008 17:42:41 -0500
- Subject: Re: [PATCH] Optimized __cxa_guard_{acquire,release,abort} for Linux
- References: <20071231133948.GQ20451@devserv.devel.redhat.com> <84fc9c000712310800pb646954y47cd3c52fcf0dd4f@mail.gmail.com> <47791391.9050901@suse.de> <20080102102916.GT20451@devserv.devel.redhat.com> <477E8E06.5000001@redhat.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Jan 04, 2008 at 02:50:30PM -0500, Jason Merrill wrote:
> This looks great, and I think should definitely go into 4.3. One
> question: why do you need all the cmpxchg in the abort/unlock functions?
> If we're in those functions, we already got the lock, so no other
> thread should be modifying the guard. Can't we just do a non-atomic
> assignment and then FUTEX_WAKE?
We could do a non-atomic store I guess (provided __cxa_abort is never
called by mistake when the the var has been initialized already and
the first byte set), but then we'd need to do an unconditional
FUTEX_WAKE. I guess we could use instead __sync_lock_test_and_set
aka. atimic exchange, to atomically swap in 0 and read previous value
to see if we need FUTEX_WAKE or not. The unconditional FUTEX_WAKE
is IMHO more costly than __sync_lock_test_and_set and conditional
FUTEX_WAKE.
Jakub