From owner-freebsd-hackers  Wed Jul  4 12: 4: 8 2001
Delivered-To: freebsd-hackers@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 821)
	id 5466F37B401; Wed,  4 Jul 2001 12:04:04 -0700 (PDT)
Date: Wed, 4 Jul 2001 12:04:04 -0700
To: Hackers List <freebsd-hackers@FreeBSD.org>
Subject: pthreads vs set/longjmp performance (homegrown tasking)
Message-ID: <20010704120404.A3796@FreeBSD.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
From: jwd@FreeBSD.ORG (John W. De Boskey)
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-hackers.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-hackers>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-hackers>
X-Loop: FreeBSD.ORG

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