i386 libstdc++ priority inversion issue
Stephen Warren
swarren at wwwdotorg.org
Sat Sep 24 03:48:14 UTC 2005
I'm assuming that the uClibc mailing list is an appropriate place for
buildroot discussions - couldn't find a buildroot specific list on
uclibc.org...
We recently built a toolchain using buildroot, and elected to build
libstdc++ too, since our app is C++. We selected i386 as the architecture.
We found that this setting causes libstdc++ to use spinlocks to protect
some operations, such as std::string::~string (the implementation uses
ref counts, and a spinlock is used for thread-safety)
This causes issues in a multithreaded app that sets explicit
kernel-level scheduler priorities, since a low priority thread can get
de-scheduled with the spinlock held, then a higher priority thread can
attempt to lock the spinlock. Since the high-priority thread is spinning
on the spinlock and never yielding the CPU, and is hence always
runnable, the lower priority thread never gets to run, and never
releases the spinlock, and hence the system (app) grinds to a nasty halt.
We found the simplest way to prevent this was to build libstdc++ for an
i486. This causes new atomic increment-and-exchange assembly
instructions to be used to implement the ref counts, instead of a
spinlock wrapping a non-atomic increment-and-exchange operation.
We built for i486 by hacking buildroot's Config.in to allow a new "i486"
option, which then gets passed around as config triplet
i486-uclibc-linux (instead of the "default" i386-uclibc-linux).
Should this new option (and i586, etc.) be added to the standard
Config.in? Or, should we have just added e.g. -m486 (or whatever it is)
to BR2_TARGET_OPTIMIZATION.
I'm not sure if we really had to change the target triplet for libstdc++
to change its behaviour, or if extra optimization options would have
triggered something in configure to do the right thing?
--
Stephen Warren, Software Engineer, NVIDIA, Fort Collins, CO
swarren at wwwdotorg.org http://www.wwwdotorg.org/pgp.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20050923/496849af/attachment.pgp
More information about the uClibc
mailing list