This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Glibc, Pthread, Futexes and malloc
- From: Antonio Barbalace <antoniob at vt dot edu>
- To: Ondřej Bílka <neleai at seznam dot cz>
- Cc: libc-help at sourceware dot org
- Date: Sun, 16 Mar 2014 17:31:05 -0400
- Subject: Re: Glibc, Pthread, Futexes and malloc
- Authentication-results: sourceware.org; auth=none
- References: <CAJzJ9czuaJ8XfqUyoa6Gctr6zOVm=LFsfxDiBa9EfQfUEbABvg at mail dot gmail dot com> <20140314102155 dot GA15258 at domone dot podge>
I am maybe wrong but by using glibc cross reference (e.g.
http://code.metager.de/source/search?q=lowlevellock.h&defs=&refs=&path=&hist=&type=
) it seems lowlevellock is always associated with nptl
(i.e. it is not included by any part of the code different from nptl).
So I checked who is using the functions declared in:
/gnu/glibc/nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.h
and turns out that pthread, sem and AIO are using them.
Therefore if I want to avoid futexes I have to provide a replacement
for pthread, sem and AIO. Correct?
Is there any mechanism similar to atfork in pthread_create/createthread?
many thanks for your help,
Antonio
On Fri, Mar 14, 2014 at 6:21 AM, OndÅej BÃlka <neleai@seznam.cz> wrote:
> On Fri, Mar 07, 2014 at 03:12:08PM -0500, Antonio Barbalace wrote:
>> For a project that I am developing I am using glibc but I should avoid
>> to use pthread (nptl).
>>
>> The project consist of a modification of the Linux kernel in order to
>> create a single image OS on different nodes: threads (not processes!)
>> run on a node but also across nodes. Currently we do not have the
>> support for futexes. (have a look at www.popcornlinux.org)
>>
>> After copy and paste the basic threading functions from pthread, by
>> removing futexes, in a new library, cthread
>> (http://www.barbalace.it/antonio/projects/cthread.tar.gz) .. I was
>> wondering IF:
>>
>> - does exist a version of glibc without futex ?!
>
> no.
>
> We are rewriting malloc now, one thing is that locking should not be at
> hot path and use atomics for returning memory between threads.
>
>> - in glibc scoping out malloc and printf how much of the other code
>> rely on futex?
>
> We use internal locking (see lowlevellock.h) file mainly to avoid
> linking everything with pthread. You could try to replace these with
> your primitives.
>
>> - is there any chain of per thread initializers (*_atfork) for nptl
>> that I have to take care of?
>> - e.g. is malloc_atfork called after do_clone?
>>
--
Dr. Eng. Antonio Barbalace, PhD
Systems Software Research Group (SSRG)
Bradley Department of Electrical and Computer Engineering
Virginia Tech
352 Durham Hall (0111)
Blacksburg, VA 24061
phone: +1 (540) 231-2494
email: antoniob@vt.edu