Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 Jul 2001 12:04:04 -0700
From:      jwd@FreeBSD.ORG (John W. De Boskey)
To:        Hackers List <freebsd-hackers@FreeBSD.org>
Subject:   pthreads vs set/longjmp performance (homegrown tasking)
Message-ID:  <20010704120404.A3796@FreeBSD.org>

next in thread | raw e-mail | index | archive | help
Hi,

   I have an application which uses a homegrown tasking mechanism.
Basically, it uses setjmp/longjmp where the stackpointer is
modified after the setjmp and before the longjmp. This allows
multiple 'tasks' to run (serially) within the process with
each having a different stack allocation.

   The above process is then run on top of a single pthreads
thread. With the newer pthreads libraries, this code nolonger
works:

Fatal error 'longjmp()ing between thread contexts is undefined by POSIX 1003.1' at line ? in file
/usr/src/lib/libc_r/uthread/uthread_jmp.c (errno = ?)
Fatal error 'longjmp()ing between thread contexts is undefined by POSIX 1003.1' at line ? in file
/usr/src/lib/libc_r/uthread/uthread_jmp.c (errno = ?)

   Instead of possibly modifying the pthreads library, I decided
to convert the homegrown tasking to simply always use pthreads.
I have this working, unfortunately, the performance of this implementation
is much slower:

   setjmp/longjmp:

initialization time:
real time        0.12 seconds
cpu time         0.08 seconds


   pthreads:

initialization time:
real time        0.82 seconds
cpu time         0.79 seconds

   About a 7x performance loss.

   I am using 'pthread_cond_signal()' to activate each successive
thread thus avoiding the overhead of a 'pthread_cond_broadcast()'.
Pthread_setschedparam() doesn't seem to have any effect.


   Two questions:

   Has anyone dealt with type of problem before?  If so, what approach
   did you take?

   Has anyone thought of adding/implementing a (not posix standard) way
   of informing pthreads to allow multiple stacks to be swapped in and
   out on a single pthreads thread (thus allowing the previously accepted
   semantics to continue working?)


Thanks,
John


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010704120404.A3796>