RT safeness of pthread_create()

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

RT safeness of pthread_create()

Lee Revell
Hello,

I have discovered that pthread_create() is 100% realtime safe, as long
as mlockall() is used and the thread stack is preallocated:

  #define THREAD_STACK 2097152

  mlockall(MCL_CURRENT|MCL_FUTURE);

  thread_data.thread_stack = malloc(THREAD_STACK);

  pthread_attr_setstack(&attr, thread_data.thread_stack, THREAD_STACK);

  pthread_create(&thread, &attr, worker_thread, (void *) &thread_data);

With this scheme, pthread_create() is VERY fast - 150 usecs at most with
the RT kernel and a cold cache, 0.5ms with 2.6.14 vanilla.

The default mode of operation is for pthread_create() to malloc() the
stack itself which is obviously not RT safe.

It occurred to me that JACK could take advantage of this by
preallocating a pool of thread stacks.  With a fast enough machine + low
DSP load it may even be possible to prevent xruns on client connection.
It would also greatly reduce memory usage as currently each thread eats
up 2-8MB of locked memory and remove a dependence on arbitrary rlimits.
It would also reduce the need for hacks like running new client threads
once with no inputs before adding it to the graph.

Lee



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: RT safeness of pthread_create()

Florian Paul Schmidt-2
On Mon, 07 Nov 2005 11:42:58 -0500
Lee Revell <[hidden email]> wrote:

> Hello,

Hi,

> It occurred to me that JACK could take advantage of this by
> preallocating a pool of thread stacks.  With a fast enough machine + low
> DSP load it may even be possible to prevent xruns on client connection.
> It would also greatly reduce memory usage as currently each thread eats
> up 2-8MB of locked memory and remove a dependence on arbitrary rlimits.
> It would also reduce the need for hacks like running new client threads
> once with no inputs before adding it to the graph.

Hi,

i was under the impression that during graph changes there's a lock on
the graph anyways and there's only zero cycles fed to the audio
interface. Basically all client startup xruns you see are probably due to
application bugs.

Not 100% sure though. Gurus, what's your take?

Regards,
Flo

--
Palimm Palimm!
http://tapas.affenbande.org


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: RT safeness of pthread_create()

Dave Robillard
In reply to this post by Lee Revell
On Mon, 2005-07-11 at 11:42 -0500, Lee Revell wrote:

> Hello,
>
> I have discovered that pthread_create() is 100% realtime safe, as long
> as mlockall() is used and the thread stack is preallocated:
>
>   #define THREAD_STACK 2097152
>
>   mlockall(MCL_CURRENT|MCL_FUTURE);
>
>   thread_data.thread_stack = malloc(THREAD_STACK);
>
>   pthread_attr_setstack(&attr, thread_data.thread_stack, THREAD_STACK);
>
>   pthread_create(&thread, &attr, worker_thread, (void *) &thread_data);
>
> With this scheme, pthread_create() is VERY fast - 150 usecs at most with
> the RT kernel and a cold cache, 0.5ms with 2.6.14 vanilla.
>
> The default mode of operation is for pthread_create() to malloc() the
> stack itself which is obviously not RT safe.
>
> It occurred to me that JACK could take advantage of this by
> preallocating a pool of thread stacks.  With a fast enough machine + low
> DSP load it may even be possible to prevent xruns on client connection.
> It would also greatly reduce memory usage as currently each thread eats
> up 2-8MB of locked memory and remove a dependence on arbitrary rlimits.
> It would also reduce the need for hacks like running new client threads
> once with no inputs before adding it to the graph.

Wow, nice work.  The gears are churning in my head about nifty ways to
exploit this already. :)

Especially since I'm buying a dual-core chip this month...

-DR-



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel