451061@UOTTAWA.BITNET (Valentin Pepelea) (04/05/89)
Well, since everybody is twisting their tongues at full speed spelling out
their 1.4 wishes, I guess I should too. (There is nothing wrong following the
herd of sheep, is there?)
1. The current flags available for requesting memory blocks is MEMF_CHIP,
MEMF_FAST, MEMF_CLEAR and MEMF_PUBLIC. Add three new ones:
MEMF_PHYSICAL: This flag should request a block of memory situated in
physical memory. This will be essential once virtual memory
is implemented. Programs which require to keep their real-time
characteristcs will have to be loaded in physical memory and their data
will usually have to be put in physical memory too.
MEMF_VIRTUAL: This flag (default) requests that a block of virtual
memory be allocated.
MEMF_PRIVATE: When non-MEMF_PUBLIC memory is allocated the memory block
should still be available for read-only access by other
tasks; this new flag will indicate that read access should not be permitted.
This flag is not at all useful in a single-user OS, but if multi-user
features are ever to be added, it will be essential.
Also allocate all MEMF_PUBLIC memory in physical memory by default, unless
requested otherwise. For example messages sent over to a device-driver,
(a real-time program) have to be in physical memory.
2. Modify the linker segments definitions in order to allow programmers to
specify that some segments have to be loaded in physical memory, private
memory, etc... In other words, support the new flags mentioned above.
3. Use semaphores to enforce mutual exclusion. Currently the Sassenrath way
of implementing mutual exclusion is to use the Forbid()/Permit() functions.
Theoretically, on multi-processor machines we have to use RMC (Read-Modify-
Write) cycle instructions, since this is the only way we can insure that no
other processor will modify a semaphore at the same time. Theoretically, on
single processor machines all we have to do is disable multitasking, thus
we insure that no other task will modify a semaphore simoultaneously.
This of course is not true. A number of run-time errors could arise while
multitasking is disabled. For example a divide by zero could occur, but now
since multitasking is disabled, chances are we can not properly correct the
situation. But what we are really concerned with are page faults. If
multitasking is disabled, we cannot send messages, and if we cannot send
messages, we cannot tell the harddisk.device to perform disk I/O to page in
and out the faulting pages.
On the Amiga, the problem is further exarcerbated because semaphores are not
used anywhere. Normally if the Exec wishes to modify the memory lists, it
should request the memory_list semaphore ( P(memory_list) ), perform the
operations on it, and then release the semaphore ( V(memory_list) ). But
instead of that, the Sassenrath method simply involves disabling
multitasking, performing the operations, and re-enabling multi-tasking.
Furthermore, Sassenrath tells us in the Exec manual that if we write
programs which require mutual exclusion with other programs, may these other
programs be the Exec or user programs, we should simply use the Forbid()
Permit() combination.
So now imagine that a page fault occurs, but we find out that multi-tasking
is disabled. We know that there is a simple method of re-enabling multi-
tasking. But are we allowed to use it? The problem is that we don t know
*why* multi-tasking is disabled, did the Exec want to medify a list?, did
a user want to modify an Exec list?, did a user program merely wish to
enforce mutual exclusion? Because semaphores are not used, we don t know
what to do, and we have to crash the machine. (Guru)
Unfortunately there is no way around this because so many programs use
the Permit()/Fobid() combination.
So my suggestion is very simple here, get rid of Permit()/Forbid and use
semaphores everywhere. And use the BSET instrucion to test and set a
semaphore, not the dangerous Permit()/Forbid() combination.
Valentin
_________________________________________________________________________
"An operating system without Name: Valentin Pepelea
virtual memory is an operating Phonet: (613) 233-1821
system without virtue." Bitnet: 451061@Uottawa.bitnet
Usenet: Use cunyvm.cuny.edu gate
- Ancient Inca Proverb Planet: 451061@acadvm1.UOttawa.CAdale@boing.UUCP (Dale Luck) (04/08/89)
In article <8904041835.AA01760@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: >Well, since everybody is twisting their tongues at full speed spelling out >their 1.4 wishes, I guess I should too. (There is nothing wrong following the >herd of sheep, is there?) > > >3. Use semaphores to enforce mutual exclusion. Currently the Sassenrath way > of implementing mutual exclusion is to use the Forbid()/Permit() functions. > Theoretically, on multi-processor machines we have to use RMC (Read-Modify- > Write) cycle instructions, since this is the only way we can insure that no > other processor will modify a semaphore at the same time. Theoretically, on > single processor machines all we have to do is disable multitasking, thus > we insure that no other task will modify a semaphore simoultaneously. > I agree, Forbid/Permit is a nasty way to protect long (time) critical regions. The Sempahores are much more elegant, even though they themeselves use Forbid/Permit for their critical regions of incrementing/decrementing counters. But these are very small and usually only a couple of machine instructions. The Semaphores were first implemented by graphics to provide exclusive access to layers. It was agreed that this function was better handled by exec so the code migrated from graphics.library to exec.library before final release. It is time that the rest of the system make use of these functions. -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale