2fmlhiccup@kuhub.cc.ukans.edu (05/05/91)
I never thought it was possible to have a multitasking environment that did not allow one task to prevent others from running. If not you would not be allowed to access shared data structures and the like. Even if the 'lock' is reduced to one bit, you still have to lock access to it when someone wants to try to claim that bit. It seems possible to have a task make a copy of a data structure and then use the OS to pass it to another task and make locks not required, but at the expense of an incredible loss in performance. At the bottom level, every singls OS routine would have to prevent any other task from running in this system. In other words, in a multitasking environment, it is givent that you have to halt other tasks when accessing shared memory, or if you use locks, you still have to halt other tasks when you want to claim the lock... Jason Wilson
Fletcher@cup.portal.com (fletcher sullivan segall) (05/05/91)
>I never thought it was possible to have a multitasking environment that >did not allow one task to prevent others from running. If not you would not >be allowed to access shared data structures and the like. Even if the >'lock' is reduced to one bit, you still have to lock access to it when >someone wants to try to claim that bit. It seems possible to have a task >make a copy of a data structure and then use the OS to pass it to another >task and make locks not required, but at the expense of an incredible loss >in performance. At the bottom level, every singls OS routine would have >to prevent any other task from running in this system. In other words, >in a multitasking environment, it is givent that you have to halt other >tasks when accessing shared memory, or if you use locks, you still have to >halt other tasks when you want to claim the lock... > >Jason Wilson Basically it works out to a problem in how long you want lock the machine in a single task state. On the 68000 there is hardware support for grabbing and releasing locks (S() and V() for Semaphores.) The 68000 accomplishes this by grabbing the bus, and holding it until a read-modify- write cycle has completed. This opcode isn't supported on the Amiga basically because the 68000 can't assert bus control. Instead that is all managed by one of the custom chips. So on the amiga if we were to move to a multi-processing platform that function would have to be moved to software. A bit slower to be sure, but the point is to try an minimize the amount of time spent mono-processing. By asserting a lock on certain system structures, a program might be able to look at the structures as long as neccessary, and then release them for system maintenance, without locking out all of the other tasks from running. System routines like addtask() would simply allocate the lock for their own use before trying to add a new task to the current task structure. Meanwhile, although no new processes could be loaded, it would still be possible for independent already loaded tasks to run on each processor. -F. Sullivan Segall _______________________________________________________________ _ /V\ E-Credibility: (n -- ME) The unguaranteed likelyhood that ' the electronic mail you are reading is genuine rather than someone's made up crap. _______________________________________________________________ Mail to: ...sun!portal!cup.portal.com!fletcher or fletcher@cup.portal.com