Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc!garcon!garcon.cso.uiuc.edu!grunwald From: grunwald@flute.cs.uiuc.edu Newsgroups: comp.lang.c++ Subject: Re: Some problems in the task class Message-ID: Date: 3 Apr 89 16:48:01 GMT References: <810@eiger.iis.UUCP> Sender: news@garcon.cso.uiuc.edu Organization: University of Illinois, Urbana-Champaign Lines: 53 In-reply-to: prl@iis.UUCP's message of 2 Apr 89 15:20:02 GMT I'd looked at the AT&T Tasking library & came to basically the same conclusions that you did. It's a mess, and it's more of a mess than you might suspect. Consider porting to a compiler that doesn't require frame pointers for procedure (Greenhills on the 32K, Gnu CC on everything). All of a sudden, you find yourself copying *huge* stacks for what might be a couple of arguments. Also, adding the task to the scheduling list in the constructor for the task class is a pain. In multiprocessor environments, it leads to a parallel-unsafe implementation: one processor can be executing subclass constructors while another pulls the task off the queue to execute. Bogus. I wrote another tasking library that has a class Thread. Constructors to a thread are simple constructors, nothing more. You pass arguments, save what you need, compute what you need, etc. A thread must be explicitly enqueued to a queue (typically, one maintained as ``ThisCpu'', the abstraction for the current processor). All threads have a virtual void function called ``main''. When a thread is invoked for the first time, execution ``magically'' starts by calling the ``main'' function. When you exit ``main'', your thread kills itself. The context information for a thread is stored in another class, called a HardwareContext, allowing some seperation of the thread information and contexts. Things other than threads (e.g., the actual unix processes managing the threads) have contexts. This has worked fairly well. It runs on Sun-3's & the Encore multimax. I've written a library of C++ objects that implement either a SingleCpu or a MultiCpu scheduler. There are subclasses of the Cpu objects that that implement global-time process-oriented simulation. There are SpinLocks, SpinEvents, SpinBarriers, Semaphores, Events, Barriers, and Facilities. The entire package gets a fair bit of use here, because it's used for simulation. Someone is also using it as a simple multi-tasking library for the Encore multimax for a parallel C++-scheme interpreter. There are some complications that eventually need resolving, probably when G++ gets M.I. working. Somethings would be easier if delegation-via-pointer was available. Eventually, the whole kit-and-kaboodle will be available, probably through Gnu Libg++. -- Dirk Grunwald Univ. of Illinois grunwald@flute.cs.uiuc.edu