Multitasking in Workbench 1.3?

[Florida]

Question: If I open a drawer in Workbench 1.3 (kick 1.3) and click on DF1:, DF1: will not open until the first drawer is fully opened.  The same if I execute a program while opening a drawer, the program is not loaded until the drawer is open.  Another thought, if I save a file and try to minimize the program nothing happens until the drive has stopped.
 
Is this about physics or mechanics more than multitasking or am I just not understanding it?  It is not a problem, just something I am curious about.
 
Had to look up the word 'physics', I wasn't sure if that was the right word. Explanation: The science of matter and energy and of interactions between the two, grouped in traditional fields such as acoustics, optics, mechanics, thermodynamics, and electromagnetism, as well as in modern extensions including atomic and nuclear physics, cryogenics, solid-state physics, particle physics, and plasma physics. From answers.com

[Matt_H]

What you're describing is asynchronous operation, not multitasking. Technically, Workbench is a single program, so you can run other things alongside Workbench, but Workbench itself can usually only do one thing at once.

Newer versions of Workbench have some asynchronous functions, thanks to revised code and patches like ASyncWB. An accelerator or hard drive helps a lot, too.

[MelbourneBen]

@ Florida.... Interesting question...

I was decompressing a DMS file to DF0: the other day whilst at the same time trying to create a new drawer on my HD. When creating the Drawer the floppy disk writing would stop until I'd completely finished creating the drawer and let go off the right mouse button.

This made me think twice about workbench being a truly multi tasking OS?? Which I'd always being led to believe it was....Does the floppy disk stop writing simply because of limited processing power and creating the drawer gets priority??

[MelbourneBen]

@Matt_h...That answered my question aswell. Thanks.

[Pentad]

I'm just throwing in my 2 cents here....

Multitasking and Multithreaded are sometimes confused in modern terms.  I think that the AmigaOS was/is a multitasking OS but I don't think that its multithreaded which causes issues like this.   It really comes down to Exec and if I had to guess I would say that its not multithreaded.   I don't know about 2.x/3.x...

Cheers!
P

[eb15]

The workbench program itself in AmigaDOS wasn't written as a multi-threaded app.  There are various workbench substitutes that are multi-threaded as far back as the pre workbench 1.3 jazzbench. Just lookup the aminet readme's on various workbench substitutes. It was considered a nice feature to implement because folks got tired of things taking so long to load in one window when all they wanted to do was open the next drawer inside the first one they opened, or waiting for one copy to finish to start another one. Multi-threading a file manipulation program (and GUI program launcher) does make the program more complex due to possible race conditions when various threads are working with the same filesystems at the same time along with filesystems which weren't necessarily notifying clients of changes happening underneath them and the client programs making presumptions that things weren't changing.

[itix]

I was decompressing a DMS file to DF0: the other day whilst at the same time trying to create a new drawer on my HD. When creating the Drawer the floppy disk writing would stop until I'd completely finished creating the drawer and let go off the right mouse button.

This happens because on Amiga when accessing menus it blocks all gfx output. It was one of many tricks to make system more efficient. It still multitasks but anything trying to display new gfx content on that screen is blocked.

There is a utility called MagicMenu which replaces standard blocking menus by non-blocking menus but it is also much slower.

[ElPolloDiabl]

From my experience 1.3 was only multitasking via cli shells.
3.1 should be fully multitasking.

[Matt_H]

This happens because on Amiga when accessing menus it blocks all gfx output. It was one of many tricks to make system more efficient. It still multitasks but anything trying to display new gfx content on that screen is blocked.

There is a utility called MagicMenu which replaces standard blocking menus by non-blocking menus but it is also much slower.

OS4.x also has optional non-blocking menus, probably using the same kind of mechanism. Does MorphOS also have them? Can't recall if I've ever tested.

[itix]

OS4.x also has optional non-blocking menus, probably using the same kind of mechanism. Does MorphOS also have them? Can't recall if I've ever tested.

In MorphOS it is always non-blocking. IIRC MorphOS inherits its menu system from AROS where it is the same.

[Florida]

Thanks to everyone for explaining!

[lsmart]

Multitasking and Multithreaded are sometimes confused in modern terms.  I think that the AmigaOS was/is a multitasking OS but I don't think that its multithreaded which causes issues like this.   It really comes down to Exec and if I had to guess I would say that its not multithreaded.   I don't know about 2.x/3.x...

The reality is somewhat different. Amiga always had (and still has) "tasks" and "processes". While a Unix process can´t easyly access another processes memory and have a lot of overhead, there was a need for some sort of more lightweight multitasking. Hence the invention of threads. So Amigas tasks resemble threads in many ways.

[Hattig]

@ Florida.... Interesting question...

I was decompressing a DMS file to DF0: the other day whilst at the same time trying to create a new drawer on my HD. When creating the Drawer the floppy disk writing would stop until I'd completely finished creating the drawer and let go off the right mouse button.

This made me think twice about workbench being a truly multi tasking OS?? Which I'd always being led to believe it was....Does the floppy disk stop writing simply because of limited processing power and creating the drawer gets priority??

AmigaOS is a proper multitasking operating system.

Workbench is an application running in AmigaOS.

Workbench 1.x is really rather rubbish and single-threaded, hence the 'serialised' behaviour being witnessed when accessing built-in Workbench functionality. In the case of file system access it is possible that Workbench grabs a lock on the entire HD until you've done your folder creation - I don't know the exact means Workbench works. If you do a mkdir in AmigaShell whilst DMSing, does that behave the same?

If you run, for example, a MOD player, a fractal program, and more, at the same time from workbench, then they don't stop when you do something in Workbench, although sharing resources will slow the fractal program down, and without priorities on the processes the MOD player could be starved by a very intensive process taking up all the CPU resources.

[itix]

The reality is somewhat different. Amiga always had (and still has) "tasks" and "processes". While a Unix process can´t easyly access another processes memory and have a lot of overhead, there was a need for some sort of more lightweight multitasking. Hence the invention of threads. So Amigas tasks resemble threads in many ways.

Amiga tasks and processes are practically the same thing. Tasks have some limitations (no DOS access) but they are scheduled just like they were processes and vice versa.

One could say in Amiga all tasks and processes are just threads running under kernel.