Talk:Multiprocessing

Software lockout

Article needs to discuss the issue of Software lockout. Some reference: 1968!!

Theoretical?

Is this (article as of June 2007) all theoretical? Or do actual multi-CPU processor boards exist in the consumer marketplace? And no, I'm not talking about "Dual Core" CPUs... Here's a theory: Intel and AMD know it would be much cheaper for consumers to buy two 2.8 GHz CPUs than one "2.8GHz Core Duo", so boards that support two or three CPUs are are not built. Discuss. - 128.107.159.234 06:19, 4 June 2007 (UTC)

Are you Kidding?

Multi Processor Motherboards have been widely availble since the Pentium Computer came out. ::Multi-Processor CPU Adapters have been availble for the intel 486 (Evergreen Technologies)

Some examples of early Multi-Processor comptuers are the Compaq Proliant 2500 and 5500

Tyan made dual processor Pentium II and Pentium III motherboads.

ALR Made a 6 processor Pentium Pro machine called the Revolution 6x6

Apple made a multi-processor 604e machine called the 9600MP

None of these machines are 'Dual Core' CPUs

I bought a dual pentium-pro board about 1998, and started running Win2K server on it in 2000. I ran that one many years. I bought the board in an ordinary computer store, along with the two processors, I believe for about $800. I suspect that not so many "consumers", if that means someone who doesn't know anything about computers, bought one, but they were easily within the price range for home use. Gah4 (talk) 01:40, 15 August 2016 (UTC)

The first multiprocessing system

In Annals of the History of Computing, Vol 11, No.2, 1989, Montgomery Phister described a multiprocessing sytstem which was installed in New York City in 1962 to run the Quotron stock market quotation system. It included four Control Data 160A computers connected to two 24k memories. Three of the computers and one memory were in use at any time; the fourth computer and the other memory were spares, used when a computer or memory failed.

Each of the three online computers ran a different program: one updated stock prices in the common memory; one accepted and replied to broker requests for prices; and the fourth provided stock information for United Press International.

I believe this was one of the first working multiprogrammed multiprocessing systems. —Preceding unsigned comment added by 65.19.23.84 (talk) 23:48, 30 December 2008 (UTC)

Does anybody know the shipment date for the Burroughs B5000? AFAIK it was the first master/slave multiprocessor. Also, was there an MP earlier than the Bull Gamma 60? Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:32, 14 March 2019 (UTC)

The Burroughs B5000 was apparently designed starting 1961. The Bull Gamma 60 was designed from 1957 and first shipped in 1960, so it should probably be mentioned in the History section. I will edit this section to reflect this.

Damien.b (talk) 13:23, 9 February 2024 (UTC)

Flynn's taxonomy here

This page has it backwards putting all of Flynn's here. It's true that in some books it's discussed in relation or as a way of framing what Multiprocessing as defined in the lead here means, but that's not say that everything in Flynn's is multiprocessing as defined here. Quote from: [1]:

“ The MIMD category is subdivided into two major classes:

• Shared memory multiprocessors—architectures that share a common memory (see below) and are said to be tightly coupled.
• Distributed memory (or message passing) multicomputers—architectures that use distributed memory between the processing modules, and are said to be loosely coupled

”

So it's clear that this page should be discussing only narrower topic(s) not repeat/WP:CFORK all of Flynn's. Someone not using his real name (talk) 19:35, 12 February 2014 (UTC)

I agree. I've deleted that section. Wingedsubmariner (talk) 22:38, 7 May 2017 (UTC)

Ambiguity makes the term meaningless

The term has so many meanings that it is useless to attempt to define it precisely. The term can be used to refer to multiple processes executed by a single core or processor but that definition is not stated until the third paragraph. Since that is a possible definition, it is impossible to be precise about the definition. Sam Tomato (talk) 22:53, 29 June 2015 (UTC)

No, the third paragraph was not talking about multiprocessing being used to refer to multiple processes executed by a single core or processor. What it said was

At the operating system level, multiprocessing is sometimes used to refer to the execution of multiple concurrent processes in a system as opposed to a single process at any one instant.

It didn't clearly indicate that "concurrent" means "at the same time" rather than "time-sliced on a single CPU core", but that's what the references indicated, and the paragraph later said

When used with this definition, multiprocessing is sometimes contrasted with multitasking, which may use just a single processor but switch it in time slices between tasks (i.e. a time-sharing system). Multiprocessing however means true parallel execution of multiple processes using more than one processor.

which does indicate that it involves multiple CPU cores. I've updated the first sentence in that paragraph to make that clear. Guy Harris (talk) 23:17, 29 June 2015 (UTC)

I am not sure where the use of the word "process" started being used where others use "task". It seems that everyone now know the meaning of "multitasking" (that is, outside computing). Multitasking should be used for multiple tasks (whatever you call them) on a single threaded CPU. Gah4 (talk) 01:36, 15 August 2016 (UTC)

The term "process" in the sense of "address space and (at least one) thread of control" dates back to at least Multics.

As for "task", in OS/360, the term "job" was used, and, in OS/360 MVT, what is currently called a "thread" was called a "task". Then again, in Mach, a "task" is somewhat akin to a process and a thread is called a "thread".

And I'd still call it "multitasking" if you add a second CPU or CPU core. Guy Harris (talk) 02:35, 15 August 2016 (UTC)

IBM had in the S/360 days, the 360/65MP running its special version of OS/360. Also, the names of MFT and MVT, Multitasking with a Fixed/Variable number of Tasks. If you don't do ATTACH, then a task corresponds to a job. Also, OS/360 (and OS/VS1 and OS/VS2) run all tasks and the OS itself in a single address space. I am not sure how to compare a Posix thread to an OS/360 task or subtask. Gah4 (talk) 23:06, 15 August 2016 (UTC)

Yes, OS/360 had "multiprogramming"/"multitasking" whether it ran on a single processor or a dual-processor Model 65. On a dual-processor M65, two tasks could be running at the same time without multiplexing the CPU, but there could be more than 2 ready tasks at a given time, in which case you'd still be multiplexing the CPU between tasks even on an MP system, so it's not as if running multiple threads of control by multiplexing one or more processor cores is a single-core thing only.

Looking at the Concepts and Facilities manual, they don't seem to have a specific term for what we'd call a "process" - I guess it could be thought of as a "job step" (not "job", I'd misremembered), but they say "(The performance of a task is requested by a job step.)", so "job step" isn't really an equivalent term.

Tasks could, if the hardware and OS supported it, be protected from each other, but, as you note, that didn't involve separate address spaces; that didn't happen until MVS. I guess, in OS/360 and pre-MVS OS/VS, the closest thing to the notion of a "process" would be "the task or tasks running a particular program". In MVS, a particular program would be running within a particular address space, so it'd be "the address space and the task or tasks...", which is pretty much the modern concept of "process" on most OSes.

The IBM OS where it gets tricky is their single-address-space-by-design-and-intent System/38 Control Program Facility and its IBM i descendant. The System/38 Control Program Facility Concepts Manual discusses "work management" but nothing pops up in a casual reading that corresponds to processes and threads within a process. They say:

Within a job, any number of related or unrelated functions can be performed. On many systems, the execution of programs within a job is controlled through the use of job steps, which are identified in the control statements that make up the job. However, in System/38, programs can call other programs by using control language commands contained in the calling program. Thus the job is simply made up of the sequence of processing actions a system user wants performed. The functions might be requested in:

• A series of control language commands
• A single program
• One or more applications that are each made up of a series of programs

I don't know whether "call other programs" means "run them as some sort of separate entity" or "run them by a procedure call" (Multics-style) or something else. A quick look for IBM i documentation about this doesn't seem to show anything clearer.

A hypothetical single-address-space OS, in which all units of code are "subroutines", and running a "program" just means "call the subroutine corresponding to that 'program'" (which is the way a command works in Multics - the shell runs a command by getting a pointer to a function that's the "main" program (PROC OPTIONS(MAIN), presumably) and calling it, so each user session only ever has one process), might not have any notion corresponding to a "process". It could support "multitasking", which would be like "multithreading". There might be a "run this subroutine in a subthread" primitive, and a thread and its subthreads might be something somewhat like a "process", but that's a lot vaguer. Guy Harris (talk) 00:36, 16 August 2016 (UTC)

Some of the description of MVS tasking is described along with the ATTACH macro instruction. It seems that in MVS, a jobs step, including its subtasks, executes in an address space. There is also an asymmetry that I don't believe exists with unix fork(), in that if a parent task terminates, all its subtasks are abnormally terminated. There are no zombies. In the single task case, OS/360 (and successors) have XCTL, similar to unix exec, where the new program replaces the old. Then there is LINK, where the new program is run, while the caller waits, so equivalent to unix fork(), exec(), and wait(). I believe the caller can recover if the LINKed program is abnormally terminated. And then there is ATTACH. (I believe on single task OS (OS/360 PCP) ATTACH is executed the same as LINK.) Gah4 (talk) 07:08, 16 August 2016 (UTC)

"It seems that in MVS, a jobs step, including its subtasks, executes in an address space." Sounds like a process with multiple threads.

"There is also an asymmetry that I don't believe exists with unix fork(), in that if a parent task terminates, all its subtasks are abnormally terminated." fork() creates processes, not threads; it - or it plus one of the exec calls - would correspond to creating a new job step, not just a new task. Creating a subtask would be equivalent to pthread_create().

A quick check of the Single UNIX Specification seems to indicate that if a thread terminates (by calling pthread_exit() or, except for the initial "main" thread, returns from the initial function specified when the thread was created with pthread_create()), other threads, including any threads created by that thread, continue to run. If the entire process exits, by returning from main() or calling exit(), all threads are terminated.

I'm not sure what the MVS equivalent to a fork/exec pair or to process_spawn(), i.e. a call that creates a new address space and starts a new task, running some program, in that address space, and doesn't cause the task executing the call to block until the new task terminates, would be. That might be done with an undocumented call or a "system programmer's interface" call. There appears to be a documented ASCRE macro, to create a new address space, in z/OS, but it didn't show up in the older MVS manual I linked to above. From this document it sounds as if the ability to create new address spaces is a relatively new capability. Guy Harris (talk) 09:40, 16 August 2016 (UTC)

ATTACH sounds equivalent to pthread_create().

In any case:

• There's "supporting N independent threads of control on a system with M processors, where N > M", which can exist regardless of whether M = 1, and which this page speaks of as multitasking, as does the linked-to page.

• There's "having more than one processor core in a system", which is what this page - multiprocessing - discusses.

I'm not sure I see the ambiguity for either term. You can do "multitasking" with one CPU core or with several CPU cores; if you have a number of threads of control <= the number of CPU cores, you don't need to do any multiplexing; however, I don't know of many systems that support "multiprocessing" but don't support multiplexing of tasks, and if you happen to be lucky enough, at some point in time, not to have to multiplex any of the CPUs among threads of control, that might not be true at some later point in time, either because new threads of control are created or because some existing blocked threads become unblocked. Guy Harris (talk) 09:40, 16 August 2016 (UTC)

References

SIMD multiprocessing now used in more than just supercomputing

The article formerly claimed that "SIMD multiprocessing finds wide use in certain domains such as computer simulation, but is of little use in general-purpose desktop and business computing environments." The edit removing it said "At least Excel now can run multicore, and could be a common business use of computers.", but multicore is "multiprocessing" in the sense of this article, and, as this article says, "In Flynn's taxonomy, multiprocessors as defined above are MIMD machines.", so that doesn't seem to be an example of SIMD in general-purpose computing.

However, SIMD is used in video processing, which is a lot more common on general-purpose computers these days. IBM's added some SIMD instructions to z/Architecture for "big data" analysis, and SIMD instructions are probably used on other architectures for the same purposes.

(Does anybody know whether Excel uses the various generations of Streaming SIMD Extensions?)

So, yes, the claim that was removed no longer appears to be true. Guy Harris (talk) 22:28, 14 August 2016 (UTC)

I was going between "multiple core" and "multiprocessing", as they are somewhat connected. At the time, I was thinking about multicore. Thanks for the note. Gah4 (talk) 01:32, 15 August 2016 (UTC)

Deletion of Multiprocessor article

I've created an AfD for Multiprocessor on this page. That page started as a redirect to this article, was made it a content fork of this article, was again replace by a redirect, and has again been resurrected as a new content fork. Both forks were created by the same user. Their edits may have been in good faith, but the result was disruptive. I think it would be best if the redirect was restored. Wingedsubmariner (talk) 22:28, 7 May 2017 (UTC)

Alternate definition

While most of the industry has used the term multiprocessing only to refer to multiple processors, Burroughs initially used it to refer to multiprogramming. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:39, 14 March 2019 (UTC)