Re: Re: [linux-sh:03198] Atomic operations from user-space?

On Fri, 2004-04-02 at 17:41, Dan Kegel wrote:
> Alex Bennee wrote:
> > I'm trying to debug some mutex code (or more correctly work around some
> > of glibc's mutex breakages with real-time scheduling)
> <snip>
> gcc comes with atomic operations in libstdc++ that might be handy;
> see <bits/atomicity.h>.
> (On my workstation, it's /usr/include/c++/3.2.2/i386-redhat-linux/bits/atomicity.h
> so don't be surprised if it's not obviously visible in /usr/include)

Thanks. I've got them on my cross-compiled libs. However having looked
at them I can't see any magic. For example:

static inline void
__attribute__ ((__unused__))
__atomic_add (_Atomic_word* __mem, int __val)
{
  *__mem += __val;
}

Doesn't seem to do anything to guarantee atomicity unless it is assumed
the code compiles to a single instruction. Unless I'm missing some magic
somewhere?

> I'm not familiar with the breakages you mention.  Can
> you give me a link to where they're discussed?

No. This is the conclusion I've come to after doing a load of work with
the Linux Trace Toolkit and I assume it only affects threads using the
real-time schedulers. Basically when a high priority thread was
unlocking a contended mutex I was seeing repeated sched_yields() (around
50, matching MAX_SPIN_COUNT 50 from linuxthreads/internals.h) until the
thread was put to sleep for 2ms.

The reason the sched_yields() didn't work was because the other thread
was a lower priority hence never going to get scheduled until the higher
priority thread got blocked (by the nanosleep).

I guess the correct solution if for glibc not to try a reschedule if the
waiting thread is a realtime of different priority. Even better would be
some sort of priority inheritance mechanism. However quite frankly the
glibc code scares me so I tried to work around it higher up by wrapping
some code around glibs (not glibc) mutex handling. Its a horrid hack
that works(-ish).

> Also, have you looked in glibc's bug tracking system for
> a bug report about the locking problems you mention?
> If not, please do, and file a bug if you don't find one.

I've had a look and there don't seem to be any (is there an easy way to
list all the bugs against pthreads rather than doing lots of queries for
various keywords?).

If the above description makes sense to you (i.e. I'm not talking
complete crap ;-) I'll happily file a bug.

> - Dan
-- 
Alex, homepage: http://www.bennee.com/~alex/
She blinded me with science!



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click