Date: Tue, 30 Nov 1999 14:03:45 -0500 (EST) From: Chuck Robey <chuckr@picnic.mat.net> To: Allen Pulsifer <pulsifer@mediaone.net> Cc: freebsd-arch@freebsd.org Subject: RE: Revisitted.. Threads goals.? Message-ID: <Pine.BSF.4.10.9911301343520.16082-100000@picnic.mat.net> In-Reply-To: <NBBBJNDFEKPEHPFCLNLHGEIJEJAA.pulsifer@mediaone.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 30 Nov 1999, Allen Pulsifer wrote: > Please forgive me for sticking my foot into this conversation. > I'm new to FreeBSD and have only been following this conversation > for a week. I don't pretend to know a lot of the theory, or even > how threads and SMP are currently implremented in FreeBSD. You can actually catch up, the discussion is in the archives, and it's very readable. It gets ahead of me sometimes, and I do that. > The purpose of threads is to provide a more efficient method > of multitasking. The goals of threads are to: > 1) minimize the amount of memory that each thread uses, > so that many (thousands?) of threads can be created; I don't think saving of memory as such is important. We need, however, to stay within shouting distance of other threads implementations (and POSIX's idea of threads) so this goal of yours is accomplished, but it's not a main goal of our effort. The fact of it being a shared memory area gives that as a side effect. Some other goals, like efficiency, motivate a shared memory area, which in turn give lower memory usage, but that's a result, not a goal. > Other items > may be shared or not shared depending on what > you are trying to accomplish. A lot of the decisions > are tradeoffs between functionality and efficiency. > For example, it would seem desirable to make the > unshared structures as small as possible, to > minimize memory use; No, it's *not* to minimize memory use. Considerations here are that increasing the amount of thread data may possible have some effect on thread context switching, and the complications of that. Memory usage is not really at all a factor. however, that may sacrifice > functionality. I am not familiar with all of the > structures involved, but maybe someone would make > a list: what structures must absolutely be > unshared, and what structures can optionally be made > unique, and what features or functionality are gained > by making them unique? A list like this would assist > in the tradeoff analysis and decision making. This isn't possible until the general strategy for implementing the threads is decided upon. The tradeoffs being considered are increased functionality against increased complexity. We want every possible feature, but if we make it too complicated, it will never be accomplished, or it will never really work bug-free. Thus we are exploring strategies to limit the complexity while increasing the things we do want, like reliability, efficiency (in use of resources), and simplicity. > Implementation details aside, it seems to me that one > of the major points Matt Dillion is looking for is > the ability for two threads, bound to the same > process, to run simultaneously on two different > CPU's. This seems to be a very desirable goal, > however, the question seems to be, what is the cost > of implementing this in terms of complexity and level > of effort? It's a key goal, and not even really subject to any argument so far. We already *do* have user-mode threading, that doesn't give this feature, and it has very obvious and regreattable consequences to efficient use of resources. Very definitely, we want N threads to be able to make use of M processors. This is extremely well documented in the mail archives. > In addition, if it is guaranteed that a thread will > not surrender the CPU to another thread in its same > process except at certain well defined times > (a voluntary surrender, a system call, a signal) > does that simplify user programming even more? Then it would no longer even fit any current thread standard, and really be close to useless for the majority of threaded programs. > Do these gains in simplicity make it worthwile > not implementing what might otherwise be a > powerful feature? I hate to say it, but it's a large step down in usefullness of our current user-mode threads, which are in themselves now considered less than optimally useful, and certainly less than optimally efficient (else this discussion would not be taking place). ---------------------------------------------------------------------------- Chuck Robey | Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770 | I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9911301343520.16082-100000>