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