Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 Dec 1998 21:32:43 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        alk@pobox.com
Cc:        tlambert@primenet.com, peter@netplex.com.au, gpalmer@FreeBSD.ORG, marcelk@stack.nl, smp@FreeBSD.ORG
Subject:   Re: Pthreads and SMP
Message-ID:  <199812082132.OAA25044@usr09.primenet.com>
In-Reply-To: <13932.22397.480607.310372@avalon.east> from "Tony Kimball" at Dec 7, 98 04:41:04 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> : I am not very satisfied nor happy with the allocation of stack in
> : the same VM space in each thread (for reasons of stack autogrowth),
> : and I would want to address that before anything else.
> 
> Yikes!  Surely you are not proposing to place the stacks of 
> distinct threads in distinct address spaces?!  This would
> impact application portability negatively.

No.  That was in fact the major Mistake Microsoft made that
caused the need for CreateFreeThreadedMarshallar() (sp?) in
order to transit objects between thread address spaces.


> : Finally, apart from affinity, kernel threads are relatively useless
> : as an implementation without cooperative user space scheduling.
> : The only OS which I am aware of having addressed these isses at
> : this point is Solaris.
> 
> Give me 1-1 threads, thank you very much, and I will be most
> happy to manage my own task pools, as this is the only way to write
> portably in the current state of play.  'Relatively useless' is an
> overstatement of the case.  Relatively useless, perhaps, for the case
> of Solaris applications relying upon the peculiarities of Solaris
> thread semantics.

OK; not useless for interoperability, only useless for actually
getting more work done than you would get done without kernel
threads; is that better?

The problem with kernel threads is that, barring everything else,
the threads will migrate randomly between processors, cache-busting
as they go, and you won't get significant benefit from having
multiple processors at all.  Only multiple processes really gain
benefit from SMP given the current scheduler.

If you really want kernel threads, you should look at the -current
list archives, and take the John Dyson assembly glue and use it,
since you could have kernel threads out your nose for less than
10 minutes worth of work.  Unfortunately, that's not a very
interesting thing to do until it would actually buy you benefit
of some kind (which explains why it hasn't been packaged up and
integrated yet).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

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



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