Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Jun 2003 23:39:42 -0400 (EDT)
From:      Daniel Eischen <eischen@vigrid.com>
To:        Marcel Moolenaar <marcel@xcllnt.net>
Cc:        Julian Elischer <julian@elischer.org>
Subject:   Re: Implementing TLS: step 1
Message-ID:  <Pine.GSO.4.10.10306192316460.14512-100000@pcnet5.pcnet.com>
In-Reply-To: <20030620031326.GA2260@dhcp01.pn.xcllnt.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 19 Jun 2003, Marcel Moolenaar wrote:

> On Thu, Jun 19, 2003 at 10:47:13PM -0400, Daniel Eischen wrote:
> > 
> > > For that matter %gs:0 need not point to the mailbox at all,
> > > since anyoen who needs to find it either has teh time to get it slowely
> > > (via wherever it DOES point), or has other ways of finding it.
> > 
> > Currently it _does_ have to point to the mailbox.
> 
> Q1: The race is only possible by the kernel changing the thread
>     pointer?

No, all the kernel has to do is swap out the currently
running thread (quantum expiration, interrupt, page
fault, etc) and send it up as completed on a different
KSE.  The UTS can't stop interrupts from happening in
the kernel, so a lot can happen to cause the currently
running KSE (and its currently running thread) to
be swapped out.  If the process' next KSE (within the
same KSE Group) to be scheduled is not the last KSE,
then the thread from the last KSE goes up as completed
on the new KSE.  Now the thread's notion of "what KSE
am I on" is wrong (if it is cached).  For the most
part, this is OK.  But in critical regions it is not.

> Q2: Given that libthr has been ported to ia64, what needs to be done
>     to port libkse to ia64 (roughtly)?

libpthread/arch/i386/include/ksd.h:

  #define _ksd_curkse             ((struct kse *)KSD_GET_PTR(mbx.km_udata))
  #define _ksd_curthread          KSD_GET_PTR(curthread)
  #define _ksd_set_tmbx(value)    KSD_SET_PTR(mbx.km_curthread, (void *)value)
  #define _ksd_get_tmbx(value)    KSD_GET_PTR(mbx.km_curthread)
  #define _ksd_readandclear_tmbx  KSD_READANDCLEAR_PTR(mbx.km_curthread)

  int     _ksd_create(struct ksd *ksd, void *base, int size);
  void    _ksd_destroy(struct ksd *ksd);
  int     _ksd_getprivate(struct ksd *ksd, void **base, int *size);
  int     _ksd_setprivate(struct ksd *ksd);

  For archs other than i386, this is probably just simple malloc()
  and free() with a way to set the thread pointer register.

libpthread/arch/i386/include/atomic_ops.h

  atomic_swap_long(long *dst, long val, long *res);

libpthread/arch/i386/include/pthread_md.h

  You can define THR_GETCONTEXT and THR_SETCONTEXT to be
  the system calls if you want.  i386 has optimized them
  to be userland, but it should be fine if they are syscalls.

  Basically, all you really need is THR_ALIGNBYTES and THR_ALIGN().
  We don't currently use GET_STACK_*, but may at some point to
  check for inappropriate longjmps()/setcontexts() (thread's shouldn't
  be jumping out of their own stacks, but if they want to, I guess
  why should we stop them!).

libpthread/arch/i386/i386:

  The functions thr_enter_uts() and thr_switch().  These are
  really the only functions that require much thought.  For
  someone who knows the ucontext for ia64 and how it is saved
  and restored, it's probably a snap.

There may be more MD header files than we need, but it was
a first shot at abstracting out the MD stuff.  There shouldn't
be any MD stuff other than in libpthread/arch.

-- 
Dan Eischen



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10306192316460.14512-100000>