| PLEX86 | ||
IBM 610 workstation computer 3411IBM 610 workstation computer 3412 one of the issues may be that some state involves syncronous updating of multiple memory...
It is normal for locks to have timeouts which trigger some sort of recovery. Beyond reporting the fault and its location the recovery is "implementation dependent". Everything from ignoring the lock to restarting all the computers. In the system I had problems with the local bus was locked but the global bus was not. When the first CPU unlocked the area two other CPUs entered simultaneously. The lock code was in an buttembler macro that was called from all over the place. On single CPU systems I found that with a round robin scheduler that cyclic scheduler order worked well. On exiting the area the next waiting process was activated. High priority processes ran more often but the low priority process they were feeding could process the data. This is application dependant and instruction set dependant. Polling has to be performed by the waiting programs or the scheduler on their behalf. The location of each lock is also application dependant but needs to be known globally and permanently in store. The index register and the automated placing of return address on the stack were great inventions that practically eliminated self modifying code. Loaders and incremental compliers are about the only programs that need to change read-write data areas into executable code areas. These programs already have privileged access to the memory management unit and its pointer table. Andrew Swallow IBM 610 workstation computer 3413 ref: so the os-360 smp kernels had a single "spin-lock" around the whole kernel ... i.e. the first thing on entering... snip
|
||||
IBM 610 workstation computer 3412 Alt Folklore Computers from Newsgroups The #1 Usenet Provider on the Internet
|
||||