@bison

I don’t think its lot of wrong with how AmigaDOS behaves, and most of it was improved on a while go, and we are not using AFFS anyway this days, I’m using only SFS2 on all my partitions. OFS is long gone from my system, only floppy disk images uses it.

Its maybe where small subset compared to Linux/Unix commands, and maybe is lack of command to pipe things input / output streams.

Last edited by NutsAboutAmiga on 27-Oct-2021 at 04:46 PM.
Last edited by NutsAboutAmiga on 27-Oct-2021 at 04:40 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Georg

Quote:

"AmiWest 2021 Day 1 Live Stream" video on YouTube at time 7:07:20 talks about being surprised that programs do Wait() after a Forbid(). I'm surprised such standard stuff is surprising to Exec(SG) developers ...

I was surprised he was surprised. This is an old one and has been known about for years. As well as being a standard technique. Of course investigating why code needs to run solo unless waiting should be done. But if the code couldn't break and wait the system would freeze so it's a good idea!

@Hypex

but how the heck does it work? can you explain it.

As far as I know only posix or C++ stuff will generate exceptions or breaks, (well maybe bsdsocket does, but you won’t run that in forbid.)

Last edited by NutsAboutAmiga on 27-Oct-2021 at 04:50 PM.
Last edited by NutsAboutAmiga on 27-Oct-2021 at 04:43 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Mobileconnect

Quote:

All problems with writing to structure directly that might disappear while you're using it, can be eliminated by soft-deleting structures

It's not that just that. The main problem is modifying a structure. It's common to change list nodes and list pointers. That operation needs to be locked so one process doesn't trample on what another process is doing and crashy crashy crash crash.

In practice a Forbid() is generally fine but the problem is globally it halts two cores at once. So now it's a big deal. Another way might be to keep all related programs on one core so they don't halt the other core. But there would still be crossover.

If AmigaOS used system calls like a "normal" OS this would be less of an issue. Even though they have overhead. But in any case the OS needs to provide a function still. Running as a soft interrupt instead would guarantee hi pri exclusive access until the job is done. An inverted approach might be to cache each Forbid() call and defer it instead of letting each task immediately gain control, then inside an interrupt run the sensitive routines. Another could be to delay any changes to ports, lists and any public structures if a task on the opposite core is in a lock. It's complicated.

Last edited by Hypex on 28-Oct-2021 at 05:25 PM.

@Hypex

Well this is why I started the thread with the question 'what are all the reasons you use them' so that we can see if there's a set of solutions to cover all common cases, rather than one global solution.

So for the use case where you want to discover a message port or other resource, and use it but make sure the rug isn't pulled out from under you, that's easily solved with recyclable object pools at the expense of less efficient (but also less liable to fragmentation) memory use, which should be fine in a world where we all have multi MB machines now.

For the use case where you're going to poke into system objects directly rather than using APIs to do it safely, that's much harder I agree. In a virtualised world of 68K on PPC it should be possible to do something like a copy on write where basically if your application writes to certain protected areas, your entire virtualisation is cloned and separated from any other 68K apps also running. This assumes there's a UAE like sandbox built in to the OS too, which there isn't. Heck, on a 2GB OS4 machine, why shouldn't I have a 512KB memory allocation containing a virtualised OS3 memory space attached to every single process? That's nothing.

Still I struggle to think of examples where people are actually doing poking of system lists in KS2+ software. What I'd do therefore is solve the problem a different way - look what minimum version of dos library the application opens, and if it opens a too-old version, only allow to 'runinuae' or otherwise warn the user the software will be allowed real forbid permit and so could lock the system, while if the app has opened a later version that implies it was written after poking system lists was no longer necessary, then make the forbid/permit calls no-op on the basis it's only going to be peeking but not poking.

For the general case, there should be something like an interrupt drive timeout, which says if you don't Permit within x milliseconds of a Forbid, sorry, fatal error your program is now dead. In Symbian OS we had the concept of a RunL which is basically like how you queue events in javascript, and if you took too long to complete the RunL then sorry, imma gonna kill your process.

Last edited by Mobileconnect on 28-Oct-2021 at 08:18 AM.

_________________

Hypex Quote:

In practice a Forbid() is generally fine but the problem is globally it halts two cores at once. So now it's a big deal. Another way might be to keep all related programs on one core so they don't halt the other core. But there would still be crossover.

Forbid() is often used to access shared AmigaOS data (usually structures and lists) which are global to all cores with SMP enabled. Designating related tasks to a single core will not prevent the shared AmigaOS data from being accessed at the same time on other cores.

Hypex Quote:

If AmigaOS used system calls like a "normal" OS this would less of an issue. Even though they have overhead. But in any case the OS needs to provide a function still. Running as a soft interrupt instead would guarantee hi pri exclusive access until the job is done. An inverted approach might be to cache each Forbid() call and defer it instead of letting each task immediately gain control, then inside an interrupt run the sensitive routines. Another could be to delay any changes to ports, lists and any public structures if a task on the opposite core is in a lock. It's complicated.

I don't like the idea of promoting the priority for a forbid section to block other tasks. Disabling multitasking for the core the way it is now in Forbid() should be adequate. I believe your "inverted approach" is closer to what I described as queuing tasks calling Forbid() before they enter the critical forbid code section so other cores after the next task switch timer interrupt will see the !IsListEmpty(ForbidQueue) and wait or spin the core so the queue can be emptied one at a time by executing the forbid sections on the cores where they are found. I don't see any advantage to use an interrupt for the forbid section though.

Note: I am assuming a different task scheduler for each core instead of one for all cores.

@Mobileconnect
I know you are brain storming and trying to help but most of your ideas are not usable. I believe your understanding would increase if you read some related papers. I posted the following paper but I doubt you read it.

A Lock-Free Multiprocessor OS Kernel
https://cs.uwaterloo.ca/~brecht/servers/readings-new/massalin91lockfree.pdf

The article is from before multicore SMP. The authors implement likely one of the earliest implementations of multiprocessor SMP (before it was called SMP) on affordable hardware. Many flavors of Unix were still designed for a single processor multitasking kernel like the AmigaOS. Many kernel data structures and critical code sections were protected by disabling interrupts and signals similar to the way Amiga software uses Forbid() and Disable(). The paper describes the problems and how they efficiently fixed them with lock free (non-blocking) atomic instructions (68k CAS and CAS2). Multiprocessor SMP is often more difficult to implement than multicore SMP except for POWER with the weak memory model and non-atomic memory which is similar. POWER was designed for networked multiprocessor SMP and multicore SMP where providing greater guarantees for multicore SMP was not seen as an advantage and may restrict the number of cores which can be networked. Compatibility was not a concern for POWER networks or the OS in this paper but the OS shows how to properly implement SMP with so few guarantees. It doesn't show how to implement software kludges to maintain code compatibility.

The only way to potentially avoid SMP kludges while maintaining Amiga compatibility is to make the multicore guarantees more similar to single core multitasking guarantees. Such hardware would rule out multiprocessor SMP and likely limit the number of multicore cores which can be kept synchronized but this is similar to HSA (like modern consoles use) which maintains cache coherency communication over a more limited distance.

For reference, I made a related post in another thread.

https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=44313&forum=14&start=120&viewmode=flat&order=0#845544

Last edited by matthey on 28-Oct-2021 at 12:58 AM.
Last edited by matthey on 28-Oct-2021 at 12:57 AM.

Forbid/Permit will never work good on multicore.
It will never be true SMP. (AROS SMP is cheat they use one copy of exec per core).
Forbid/Permit and all code depends on it should be dropped and replaced by something modern.

@matthey

You misunderstand me, well I doubt you read my posts at all. (i.e. don't patronise me, jerk). I don't believe in there being any point in implementing SMP at all for AmigaOS3/4, as I've said elsewhere, use the second core for application specific critical sections, like how WarpOS is used.

_________________

@ppcamiga1

Quote:

AROS SMP is cheat they use one copy of exec per core

And once again you are proving that you have absolutely no idea about that. There is only one exec on smp build of aros.

@michalsc

add binary integration to ppc version of aros
and prove this smp works with old software

@ppcamiga1

Why don't you read, what michalsc wrote?

Why don't you stop writing BS?

_________________
Sometimes we give people a lot of credit just because they’re writing nice sentences even if it isn’t adding up to much.

@ppcamiga1

that is not possible (both)

Aros has nothing like petunia but uses UAE to run 68k software
Second SMP version is based on X64 (64bit) version of Aros. There is not much software ported to X64 yet. ABI0 (Icaros Desktop and so on) is based on 32bit. Software has to be adapted and recompiled for it.

And Michal already explained it... one exec

Last edited by OlafS25 on 28-Oct-2021 at 12:06 PM.

@Birbo

Is that a serious question?

_________________
This is just like television, only you can see much further.

@BSzili

Of course

_________________
Sometimes we give people a lot of credit just because they’re writing nice sentences even if it isn’t adding up to much.

@NutsAboutAmiga

I can understand it but explaining it is another matter. It's actually in the design. There is the global TDNestCnt in Exec and a local one in the Task structure. So when a task is in a Forbid() lock the global system state is stored in Exec so it knows not to switch it out. But if a task performs an action that ends up calling a Wait() it logically can't stay locked or the system would freeze, waiting for another task disabled from working. So in this case the count is transferred to the task and global count is normallised so task switching works again. When the task is reactivated the count is transferred back to Exec and system is relocked. It's fine if you just need it for small portions. But it is a flawed system of working.

@Mobileconnect

Most of the time it is due to poking into system lists. Because that is the standard way of doing it. In most cases the system doesn't even provide functions to do it. The node and list functions are general with no specific arbitration mechanism in place. An an example, if you want to simply know if a device exists, you must pull the list from Exec then call a FindName() on it inside a Forbid() lock. To avoid the setup of an OpenDevice() call.

Lists and other objects like MsgPorts aren't designed to be locked. Lists have a pad byte so that could be a locking count. But it needs to be added in.

And needed it in early. So the design was like that from the begining. Which is problematic now because they didn't include any standard system way of accessing system structures. They let the programs roam free. Suppose it's an open design. A ddecade later they are sending messages out to avoid Forbid() at all costs but at the same time provide no other means of avoiding it nor adding safe functions for doing so to migrate software away. Exec added functions for allocating ports but nothng for locking system ones. As if they left it too late. And OS4 left it too late again. Had they thought about it 20 years ago or in the least done something in OS4 it would be less of a hassle now.

@michalsc

Quote:

And once again you are proving that you have absolutely no idea about that.

He is right about that "Forbid/Permit will never work good on multicore". So for multi core (not SMP) instead of only multiple execs what you want is multiple complete A(R)OS instances (= multiple exec/intuition/graphics/everything) running at the same time. At least one per big app. An idle AOS instance takes basically no cpu time at all (there's just some timer ticks going through input.device). You could easily run 1000s of AOS instances at the same time. The apps can continue to use Forbid/Permit like before. You get memory protection (between apps from different AOS instances) /resource tracking (+ easy kill-ing of apps) /multi core support for free. You could mix 32 bit/64 bit apps.

@Hypex

Good points well made thanks.

_________________

Hypex Quote:

Most of the time it is due to poking into system lists. Because that is the standard way of doing it. In most cases the system doesn't even provide functions to do it. The node and list functions are general with no specific arbitration mechanism in place. An an example, if you want to simply know if a device exists, you must pull the list from Exec then call a FindName() on it inside a Forbid() lock. To avoid the setup of an OpenDevice() call.

Right. The AmigaOS uses doubly linked lists extensively (including often for queues and stacks) and most of the time there is no arbitration other than using Forbid(). Forbid() was low overhead and required minimal code for multitasking single core use but the former does not apply to multicore SMP. The paper I linked above chose arbitration over each list node as the nodes were transversed with VisitNextNode() and ReleaseNode() as examples. While this fine grained arbitration had the advantage of likely minimizing deadlocks and race conditions (contention for the same atomic RMW addresses), it required a node refcnt while existing AmigaOS list nodes do not have any reserved space or pading and the use of CAS2 which the PPC and most other architectures do not have. Therefore, arbitration of the whole list may be the only solution for SMP which I believe is the conclusion you came to judging by what you have written below.

Hypex Quote:

Lists and other objects like MsgPorts aren't designed to be locked. Lists have a pad byte so that could be a locking count. But it needs to be added in. And needed it in early. So the design was like that from the begining. Which is problematic now because they didn't include any standard system way of accessing system structures. They let the programs roam free. Suppose it's an open design. A decade later they are sending messages out to avoid Forbid() at all costs but at the same time provide no other means of avoiding it nor adding safe functions for doing so to migrate software away. Exec added functions for allocating ports but nothing for locking system ones. As if they left it too late. And OS4 left it too late again. Had they thought about it 20 years ago or in the least done something in OS4 it would be less of a hassle now.

Using the full list LH_pad is a good idea but it wouldn't be usable for minimal lists and PPC couldn't access the data using the atomic load reserve and store conditional instructions (lwarx and stwcx) as a byte access is not supported. The atomic 68020 CAS.B instruction would support the access but it is not reliable in chip memory on original Amiga hardware and the AmigaOS is currently compiled for only a 68000. There is no problem on custom 68k hardware though.

Gunnar von Boehn Quote:

Looking at SMP. Doing SMP did traditionally had some challenges on AMIGA. Interestingly we fixed a number of them already. a) Problem TAS/CAS/CAS2 The 68k provides hardware instruction for SMP syncronisation. Those SMP instruction did use read-and-modify busy cycles which could collide with the old AMIGA chipmem bus cycles. This problem is fixed! Apollo in combination with SAGA has solved this collisions. These instructions can now be used as expected! b) Problem MUTEX On AMIGA applications have several ways to guarantee that a certain operation is ATOMIC. One example is simply poking chipset to disable IRQ for a code block execution to guarantee that the OS-schedular will called for this period. APOLLO and SAGA being in one SOC can now provide compatibility to this behavior also over more than one core. This means SAGA offer snooping of this and can "hold" all cores when MUTEX code is protected like this. c) Cache coherence and Selfmodify code APOLLO Caches are by design coherent. This is done fully in Hardware and not Operating systems calles are needed for this. Also compatibility and support for selfmodifying code is guaranteed by the hardware. While SMP in AMIGA is never easy to do. APOLLO 68080 is currently the hardware having the best designed abilities for this. APOLLO 68080 is also MUCH better designed for this than all PowerPC cores.

Custom 68k hardware can remove many incompatibilities and provide unprecedented opportunities to workaround problems which are not possible with software solutions. While custom 68k hardware has the best chance to retain useful software compatibility with SMP, it is unlikely to happen in a FPGA because a $40 FPGA may cost $80 with 2 cores while a $5 ASIC may cost $7 with 2 cores. Gunnar hyper-optimizing the core design and ISA for an affordable FPGA instead of doing the R&D for SMP in a much bigger and more expensive FPGA while making it ASIC ready sadly provides a self fulfilling prophesy by him that an ASIC is out of reach.

Rather than lock the whole list for accesses, it would be better to allow multiple list reads with a read lock count but provide only an exclusive lock for writes when the read lock count is zero. The read is similar to the behavior of ObtainSemaphoreShared() and the write to a regular exclusive ObtainSemaphore(). Perhaps SignalSemaphores could even be used and I believe the structures need not be near the lists they protect. Of course a solution to avoid the Forbid() and Permit() with accessing public SignalSemaphores would need to be found.

https://wiki.amigaos.net/wiki/Exec_Semaphores

Georg Quote:

He is right about that "Forbid/Permit will never work good on multicore". So for multi core (not SMP) instead of only multiple execs what you want is multiple complete A(R)OS instances (= multiple exec/intuition/graphics/everything) running at the same time. At least one per big app. An idle AOS instance takes basically no cpu time at all (there's just some timer ticks going through input.device). You could easily run 1000s of AOS instances at the same time. The apps can continue to use Forbid/Permit like before. You get memory protection (between apps from different AOS instances) /resource tracking (+ easy kill-ing of apps) /multi core support for free. You could mix 32 bit/64 bit apps.

Using multiple separate AmigaOS sandboxes would solve many sharing problems like SMP, memory protection, program isolation, resource tracking and security. It is tempting to consider it with the AmigaOS having such a small footprint but then it gives up that very advantage of a small footprint and the amazing resource sharing of the Amiga which is unmatched by most OSs today. Data sharing such as the clipboard and some Amiga features like ARexx interfaces would be more difficult. It would be nice to be able to launch sandboxed programs but a powerful enough Amiga can use UAE and/or WHDLoad for that.

Last edited by matthey on 29-Oct-2021 at 01:26 AM.
Last edited by matthey on 29-Oct-2021 at 01:19 AM.

@OlafS25

So SMP in AROS is untested as rest in this os.