When communciating with in a system what is that called ?

Hi

If i have a CPU and there is the Term IPC Interprocess communication to communicate with in the CPU e.g shared memory , sockets, pipes e.t.c

How do i call that when i have a system . e.g 5 cpu and the CPU will communicate with each other is there a term simular to IPC ?

Reply to
Gerald Maher
Loading thread data ...

There is the term "multiprocessor system". These can be "tightly coupled" or "loosely coupled". A book on Computer Architecture should discuss those terms.

Reply to
Gary Kato

Why even use a different one rather than sticking with the term you already have?

Just because the various processes now run on different CPUs doesn't make their communication no longer be inter-process-communcation. IPC implementation will obviously be more complicated, due to the presence of more than one processor actually working in parallel, but's it's still IPC. That would change only if you had an OS that supported several CPUs running several threads of the same processes.

[And since none of this would usually be particularly relevant to embedded computing, I suggest you ask further questions elsewhere.]
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

I think you should go else where to ask what is embedded computing! I presume you mean embedded systems because to my knowledge shared memory , sockets, pipes CPU and how a system communicates with each other belongs to Embedded Systems.

Reply to
Gerald Maher

I'm always looking for good names that provide concise distinctions, so this question rings a chord.

Along the lines of your question, I like to distinguish between IPC (Inter Process Communications), a broadly applied term, and ITC (Inter Thread Communications). The difference being that threads share a single address space whereas processes do not (ignoring shared memory segments for the moment).

In my mind, your question needs needs more background. CPU's can be connected and communicate in many different ways, none of which you specified. In the most general sense, I think you would call it "data communications". This, however, usually conjours up pictures of WANs and LANs.

Symetrical Multi Processing (SMP) systems have more than one processor sharing the same address space. In this case the processors communicate through the RAM that they share over a common bus. Also typical of SMP configurations is that the CPUs run a single copy of the operating system, and the operating system schedules threads among the CPU's. These configurations are generally availabe in high end desktop computers.

There are also other configurations where CPUs share RAM but execute independently, the logical address spaces of the CPUs are not necessarily the same, and indeed the CPUs themselves may be of different types. Such configurations are common in VME and similalr bus based systems. These configurations are common in big expensive fast real-time systems.

More common of this news group are systems that communicate over some sort of serial data link e.g. UART/RS232, I2C, SPI and HDLC.

Blah blah blah ... sorry for the rambling "non-answer" :-)

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144

"... abstractions save us time working, but they don't
  save us time learning."
Joel Spolsky, The Law of Leaky Abstractions

The Beatles were wrong: 1 & 1 & 1 is 1
Reply to
Michael N. Moran

Hi Michael

What would you call the following scenario?

I have a PC104, PowerPC, Network Processor from Intel, which runs a Real Time Operating system. And embedded linux running on a 8240, i communicate over LAN and rs232 between the devices.

I want to be able to communicate within the system.

What would you call the communication term between the device?

Multiprocessor system? System communicating ? Embedded Communication ? IPC over a system?

Reply to
Gerald Maher

I think you should go else where to ask what is embedded computing! I presume you mean embedded systems because to my knowledge shared memory , sockets, pipes CPU and how a system communicates with each other belongs to Embedded Systems.

Reply to
Gerald Maher

A big mess ;-)

Quite a bit of diversity. This is a single embedded system?

I don't quite know what to make of this statement. What do you mean by you "want to be able to communicate within the system?"

Sounds like a multiprocessor system.

Hmmm.

Hmmm.

I don't know what this means.

The only thing that I can think of that might even come close is "Distributed Computing", but that is not a term I usually associate with embedded systems, and its not really a term for communications.

Given that the mediums are LAN and RS232, and not knowing anything more about the application, I'd just call it data communications.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144

"... abstractions save us time working, but they don't
  save us time learning."
Joel Spolsky, The Law of Leaky Abstractions

The Beatles were wrong: 1 & 1 & 1 is 1
Reply to
Michael N. Moran

The problem there is normally in a embedded system you have 2 types of messages trransfers or message interface

  1. Data
  2. Commands

where data can drop messages and commands can not drop any messages.

Reply to
Gerald Maher

I have never heard this distinction made along the lines of data and commands. The term "data communications" refers to the transfer of information independent of whether that data is command or data.

I *have* heard of the following types of data communication which have to do with the delivery requirements/semantics.

At-Most-Once At-Least-Once Exactly-Once

With at-most-once transfers, a single "packet" of data is sent toward the receiver, and may or may not be actually received depending upon the network between the sender and receiver.

At-least-once transfers operate by sending the same packet several times in the hope that at least one copy of the packet is received.

Exactly-once tranfers follow a protocol of data transfer, acknowledglements and timers that, short of a major connectivity problem, ensure that exactly one copy of the packet is delivered to the receiving application.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144

"... abstractions save us time working, but they don't
  save us time learning."
Joel Spolsky, The Law of Leaky Abstractions

The Beatles were wrong: 1 & 1 & 1 is 1
Reply to
Michael N. Moran

I worked on a similar system. Very interesting project if you ever get a chance to do it. We have Mips, PPC, Linux with x86 SMP, Other RTOS with X86 etc. This kind of system is very typical for big telecom equipements. Fews CPU cards even had

2 GB of RAM in it.

Very interesting to debug. All kind of messages flying everywhere. Application might be blocked on something and claim to miss the messages from somethere else, etc, etc. Have to generate a few custome tools to debug all kind of distributed messaging issues. It is amazed that the system works at all. I thought we would be crushed to dead by the complexity of the system.

-- SLink create hyperlinks for all functions, macros, variables from thousands of files. Browse hyperlinked source code for .NET CLI, Mozilla, Apache, NetBSD, Ethereal, Chorus OS at

formatting link

Reply to
K_Lee

Interesting, telecom happens to be my background, although I've never worked on a system with *that* many different processors.

Back to the OP's question, how about:

"Distributed Computing in a Heterogeneous Computing Environment"

1/2 :-)

While I laugh at this description, it truly is a discription of some of the problems that must be solved in these kinds of systems. The trick is to get management to understand the impact on the schedule.

Indeed. Complexity managment is the name-of-the-game in telecom. The trick is to not only meet the initial "first release" requirements, but to design a framework that will allow the "next generation" requirements to be met without starting from scratch. Solid system architecture is the key to long term success.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144

"... abstractions save us time working, but they don't
  save us time learning."
Joel Spolsky, The Law of Leaky Abstractions

The Beatles were wrong: 1 & 1 & 1 is 1
Reply to
Michael N. Moran

I have work for embeded systems for the last 7 years and it is very common to combine different processors for example C16x, PowerPC, Intel PC , TMS320C25 in one system. The first problem you have is the byte order, but that is not the topic here

That was one Telecom project that i worked on which combined the Processors above.

Reply to
Gerald Maher

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.