Bug 124723 - libc.nptl spinlock code is different from kernel?
libc.nptl spinlock code is different from kernel?
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-28 16:36 EDT by Bob Cook
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-05-31 10:05:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bob Cook 2004-05-28 16:36:50 EDT
Description of problem: libc.nptl spinlock code is different from
kernel?   Presumably, one is better than the other.


Version-Release number of selected component (if applicable):
libc-2.3.3
linux kernel-2.6.5-1.358


How reproducible: compare source files
http://lxr.linux.no/source/include/asm-i386/spinlock.h?v=2.6.5#L46
libc/nptl/sysdeps/i386/pthread_spin_lock.c

#define spin_lock_string  to asm(  )

why does the library redefine anyway?
it would be cleaner to use kernel includes.


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Bob Cook 2004-05-28 16:39:05 EDT
#define spin_lock_string \from kernel -- note decb instead of decl?
47         "\n1:\t" \
48         "lock ; decb %0\n\t" \
49         "js 2f\n" \
50         LOCK_SECTION_START("") \
51         "2:\t" \
52         "rep;nop\n\t" \
53         "cmpb $0,%0\n\t" \
54         "jle 2b\n\t" \    --note jumps are reversed from library?
55         "jmp 1b\n" \
56         LOCK_SECTION_END
Comment 3 Jakub Jelinek 2004-05-31 10:05:47 EDT
Why does it need to be the same?
In the kernel, the code can assume at most 128 CPUs trying to grab the
spinlock.  glibc cannot make assumptions on how many threads are trying
to acquire the spinlock at once (well, it assumes at most 2^31 threads).

Note You need to log in before you can comment on or make changes to this bug.