[Top] [All Lists]

Re: ll/sc emulation patch

Subject: Re: ll/sc emulation patch
From: Mike McDonald <>
Date: Mon, 16 Jul 2001 12:12:08 -0700
Cc: "Maciej W. Rozycki" <>,,
In-reply-to: Your message of "Mon, 16 Jul 2001 11:47:04 PDT." <>
>To: "Maciej W. Rozycki" <>
>Subject: Re: ll/sc emulation patch 
>Date: Mon, 16 Jul 2001 11:47:04 -0700
>From: Mike McDonald <>
>>Date: Mon, 16 Jul 2001 14:03:30 +0200 (MET DST)
>>From: "Maciej W. Rozycki" <>
>>To: Ralf Baechle <>
>>Subject: Re: ll/sc emulation patch

>> I didn't profile it very extensively, yet when stracing `ls /usr/lib'
>>(fileutils 4.1 linked against glibc 2.2.3) on my system once I yielded
>>~4500 syscalls of which ~4000 were _test_and_set() (or MIPS_ATOMIC_SET,
>>depending on my kernel/glibc configuration) invocations.  Yes, libpthread
>>appears to assume atomic operations are cheap, which is justifiable as
>>they are indeed, for almost every other CPU type. 
>  Not knowing anything about the glibc architecture, I have a dumb
>question: why is 'ls' doing anything at all with pthreads?

  OK, let me rephrase this: why are ~90% of ls's syscalls calls to
_test_and_set() when 'ls' is(??) a single threaded program? Does glibc
always assume it's running in a multithreaded environment?

  Mike McDonald

<Prev in Thread] Current Thread [Next in Thread>