Sponsored Content
Special Forums UNIX and Linux Applications High Performance Computing Memory Barriers for (Ubuntu) Linux (i686) Post 302430730 by Corona688 on Friday 18th of June 2010 01:34:12 PM
Old 06-18-2010
The old system(usually known as linuxthreads) has been abandoned for many moons now. It was designed to operate without modifying the kernel, which made it a very strange beast -- it created pretend-thread processes with 100% shared memory, did all communication with signal traps, and had some very....unique bugs that turned out to be fundamental design flaws(zombie threads! Wow!)

So, no. It was not a high-performance threading model. There's only a very few things(like ulibc in embedded systems) that still stick with it these days.

With kernel 2.5 and later, they built enough things into the kernel to let them do threading properly. I've shown you bits of its code -- some fundamental things are almost down to the instruction level. NPTL is much, much better, and I've found it quite good.

Quote:
I wanted to avoid the pthreads syncrhonisation structures like mutexes because I sought to avoid their overhead and keep it scalable.
Yes, and the overhead you were worried about was the same atomic operations you're hellbent on using now. I've looked in its code and shown you some of it; it's not bloated.
Quote:
There are ways to distribute work such that mutexes aren't necessary as long as an ordering of instructions can be guaranteed, hence following your advice, I'll try those atomic instructions from GCC.
I remain stolidly unconvinced that spinlocking is more efficient than blocking. If your writer really can keep up with your readers, a proper queue might not block at all even in pthreads.
Quote:
But anyway, I needed something with more control than was on offer with something featuring a standard posix api.
Are you sure of that? You only discovered thread-specific data last week.

Last edited by Corona688; 06-18-2010 at 02:42 PM..
 

4 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

Memory-waste in Ubuntu/Debian?

I have 512 mem on this laptop, though 'top' tells me I only have 380. However, Ubuntu is using 288 mb of memory, when I only have 3 terminals, running lynx, vim(for this file) and (of course) top. Considering it I have lynx running a 600 page txt file, which of course would eat some memory but 300?... (0 Replies)
Discussion started by: riwa
0 Replies

2. Linux

i686, x86 64, ppc

Hi, i am quite new to linux. I am interested in fedora linux distro. Fedora Project I dont know which one to choose, either i686, x86 64 or ppc. I prefer a live cd, coz its easy to use. And what is the difference between "Fedora Desktop Live Media" and "Fedora KDE Live Media". (3 Replies)
Discussion started by: superblacksmith
3 Replies

3. Programming

Getting the total virtual memory for ubuntu in c++

Hi guys , i need to get the total virtual memory in ubuntu but i need to write a C++ code for that, any idea on how to go about doing it? any references? or website that i can refer to ? (6 Replies)
Discussion started by: xiaojesus
6 Replies

4. Ubuntu

XP and Linux (Ubuntu) on same disk, Can I install Ubuntu on not-yet partitioned portion of disk?

My PC (Esprimo, 3 yeas old) has one hard drive having 2 partitions C: (80 GB NTFS, XP) and D: (120 GB NTFS, empty) and and a 200 MB area that yet is not-partitioned. I would like to try Ubuntu and to install Ubuntu on the not-partitioned area . The idea is to have the possibility to run... (7 Replies)
Discussion started by: C.Weidemann
7 Replies
NPTL(7) 						     Linux Programmer's Manual							   NPTL(7)

NAME
nptl - Native POSIX Threads Library DESCRIPTION
NPTL (Native POSIX Threads Library) is the GNU C library POSIX threads implementation that is used on modern Linux systems. NPTL and signals NPTL makes internal use of the first two real-time signals (signal numbers 32 and 33). One of these signals is used to support thread can- cellation and POSIX timers (see timer_create(2)); the other is used as part of a mechanism that ensures all threads in a process always have the same UIDs and GIDs, as required by POSIX. These signals cannot be used in applications. To prevent accidental use of these signals in applications, which might interfere with the operation of the NPTL implementation, various glibc library functions and system call wrapper functions attempt to hide these signals from applications, as follows: * SIGRTMIN is defined with the value 34 (rather than 32). * The sigwaitinfo(2), sigtimedwait(2), and sigwait(3) interfaces silently ignore requests to wait for these two signals if they are speci- fied in the signal set argument of these calls. * The sigprocmask(2) and pthread_sigmask(3) interfaces silently ignore attempts to block these two signals. * The sigaction(2), pthread_kill(3), and pthread_sigqueue(3) interfaces fail with the error EINVAL (indicating an invalid signal number) if these signals are specified. * sigfillset(3) does not include these two signals when it creates a full signal set. NPTL and process credential changes At the Linux kernel level, credentials (user and group IDs) are a per-thread attribute. However, POSIX requires that all of the POSIX threads in a process have the same credentials. To accommodate this requirement, the NPTL implementation wraps all of the system calls that change process credentials with functions that, in addition to invoking the underlying system call, arrange for all other threads in the process to also change their credentials. The implementation of each of these system calls involves the use of a real-time signal that is sent (using tgkill(2)) to each of the other threads that must change its credentials. Before sending these signals, the thread that is changing credentials saves the new creden- tial(s) and records the system call being employed in a global buffer. A signal handler in the receiving thread(s) fetches this informa- tion and then uses the same system call to change its credentials. Wrapper functions employing this technique are provided for setgid(2), setuid(2), setegid(2), seteuid(2), setregid(2), setreuid(2), setres- gid(2), setresuid(2), and setgroups(2). CONFORMING TO
For details of the conformance of NPTL to the POSIX standard, see pthreads(7). NOTES
POSIX says that any thread in any process with access to the memory containing a process-shared (PTHREAD_PROCESS_SHARED) mutex can operate on that mutex. However, on 64-bit x86 systems, the mutex definition for x86-64 is incompatible with the mutex definition for i386, meaning that 32-bit and 64-bit binaries can't share mutexes on x86-64 systems. SEE ALSO
credentials(7), pthreads(7), signal(7), standards(7) COLOPHON
This page is part of release 4.15 of the Linux man-pages project. A description of the project, information about reporting bugs, and the latest version of this page, can be found at https://www.kernel.org/doc/man-pages/. Linux 2015-08-08 NPTL(7)
All times are GMT -4. The time now is 04:42 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy