Hi guys :)
I'm not quit sure if this is the right forum to post this question...
can any one describe me what is the difference between an Application which is inherently concurrent and one which is potentially concurrent?
and why is a real -time system is inherently concurrent?
any ideas are welcomed.Thanks for helping :)
> can any one describe me what is the difference
> between an Application which is inherently concurrent
> and one which is potentially concurrent?
>
> and why is a real -time system is inherently
> concurrent?
I've never heard this distinction but an inherently concurrent application must be one that handles processes that are naturally happening in parallell. This should include any application connected to the real world because there everything happens at the same time.
Potential concurrency must be when you have a sequencial process you could split up in many parallell processes if you wanted to.
I question the definition.
>
> I'm not quit sure if this is the right forum to post
> this question...
> can any one describe me what is the difference
> between an Application which is inherently concurrent
> and one which is potentially concurrent?
One system is solving a problem that requires simulataneous functionality and the other doesn't.
>
> and why is a real -time system is inherently
> concurrent?
And this is where I question the definition.
I have a circuit board around somewhere that blinks a LED. The rate that it blinks is varied by a potentiometer.
Seems like a "real time system" to me. Nothing about it is "concurrent".
The definition from wikipedia doesn't really mandate that either .... http://en.wikipedia.org/wiki/Real_time
An operation within a larger dynamic system is called a real-time operation if the combined reaction- and operation-time of a task is shorter than the maximum delay that is allowed, in view of circumstances outside the operation. The task must also occur before the system to be controlled becomes unstable. A real-time operation is not necessarily fast, as slow systems can allow slow real-time operations.
Given the above definition is suggests (but does not mandate) that a task runs based on an input signal. And that task always runs (starts running) when the signal reaches a threshold. (The task has to be done before the next threshold.)
Again this suggests, without mandating, that at least two functional blocks can be, and at some point will be, running at once. The task block and the signal detection block.
However nothing stops them from running sequentially either.
Now if you wish to define a real time system as a system that runs a task on a signal and alarms if it another signal is received before the task completes then that would require a concurrent system.
I suppose you could also argue that if a real time system does demand concurrent processing then at the absolute level most real time systems are not rreal time systems. Because with a single cpu, threading is implemented in a sequential manner and even cpu interrupts could just be handled by sequential micro-code.
> Seems like a "real time system" to me. Nothing about
> it is "concurrent".
It becomes a matter of definition. Lets say you have two such circuit boards and they're connected to a computer with an application that handles both at the same time, that is concurrenly. If you remove one circut board, does the application then cease to be "concurrent"?
> > Seems like a "real time system" to me. Nothing about
> > it is "concurrent".
>
> It becomes a matter of definition. Lets say you have
> two such circuit boards and they're connected to a
> computer with an application that handles both at the
> same time, that is concurrenly. If you remove one
> circut board, does the application then cease to be
> "concurrent"?
I am not sure who you are asking nor really what you are asking about.
So see if any of the guesses fit (first guess that you are asking me.)
The system you described is concurrent. The fact that a system at time X is not in fact running more than one functional block does not alter the nature of the system itself.
However what you described is a different system than the example I gave. And the question wasn't whether a system could be concurrent but rather if it must be. And thus if my system fits a definition of a real time system then it also must either be concurrent or not concurrent. And that system might not be a real time system but it is definitely not concurrent.
> However what you described is a different system than
> the example I gave. And the question wasn't whether
> a system could be concurrent but rather if it must
> be. And thus if my system fits a definition of a
> real time system then it also must either be
> concurrent or not concurrent. And that system might
> not be a real time system but it is definitely not
> concurrent.
(Shouldn't the first not in the last sentence above be removed?)
Anyway I don't think the OP asked about a definition of the distinction between concurrency and non-concurrency. It's about two types of concurrency, inherent and potential. So I read
"and why is a real -time system is inherently concurrent?"
as that the real-time system IS concurrent.
So the proposition is - A concurrent real-time system is always INHERENTLY concurrent.
> > However what you described is a different system than
> > the example I gave. And the question wasn't whether
> > a system could be concurrent but rather if it must
> > be. And thus if my system fits a definition of a
> > real time system then it also must either be
> > concurrent or not concurrent. And that system might
> > not be a real time system but it is definitely not
> > concurrent.
>
> (Shouldn't the first not in the last sentence above
> be removed?)
Grammatically or for intent?
Let me rephrase so the intent is clear.....
The circuit board that I described is definitely not a concurrent system.
It might or might not be a real time system depending on the definition.
If it is a real time system, then because it is not concurrent, it disproves what the OP suggested (my interpretation not what you suggested.)
Obviously if it isn't a real time system then it is not relevant.
>
> Anyway I don't think the OP asked about a definition
> of the distinction between concurrency and
> non-concurrency. It's about two types of concurrency,
> inherent and potential. So I read
>
> "and why is a real -time system is inherently
> concurrent?"
>
> as that the real-time system IS concurrent.
>
> So the proposition is - A concurrent real-time system
> is always INHERENTLY concurrent.
Ok, I can see where that might be the question.
Really needs more definitions but charging in anyways....
Using your example with the controller, normally just unplugging it would still mean that at least some processing was still concurrent (maybe just something to check if the board had been plugged back in.) To no longer be concurrent it would have to have an instruction in the controller itself that said "no longer do concurrent stuff" and that would have to run when the second board was unplugged.
And without actually designing it I can't see any reason why that wouldn't be possible.
Note that even though the instruction had run, it wouldn't change the nature of the controller system, but rather how it behaved.
So the answer to your proposition would be no.
> So the answer to your proposition would be no.
The OP asked when an application is inherently or potentially concurrent. He also proposed - a concurrent real-time system is always inherently concurrent (my interpretation).
If a problem can be or is divided into parallel processes i can be solved by a concurrent application.
1. To me an application is inherently concurrent when the problem IS naturally already divided into parallel processes. It cannot be avoided. The parallel processes are there for the application to deal with. This is how I understand inherent.
2. A potentially concurrent application on the other hand is when you have a choise. There are no natural parallel processes, but there CAN BE if you find them. This is how I understand potential.
Now the proposition. In my view any real-time concurrent application must deal with the inherent parallelism of the physical world and 1 above best describes that situation.
> > So the answer to your proposition would be no.
>
> The OP asked when an application is inherently or
> potentially concurrent. He also proposed - a
> concurrent real-time system is always inherently
> concurrent (my interpretation).
>
> If a problem can be or is divided into parallel
> processes i can be solved by a concurrent
> application.
>
> 1. To me an application is inherently concurrent when
> the problem IS naturally already divided into
> parallel processes. It cannot be avoided. The
> parallel processes are there for the application to
> deal with. This is how I understand inherent.
>
> 2. A potentially concurrent application on the other
> hand is when you have a choise. There are no natural
> parallel processes, but there CAN BE if you find
> them. This is how I understand potential.
>
> Now the proposition. In my view any real-time
> concurrent application must deal with the inherent
> parallelism of the physical world and 1 above best
> describes that situation.
A real time system doesn't deal with the entire physical world. It deals with a very small part of it.
Are you saying that there no unit of useful work in the real world that is not concurrent?
If there is even one, then it would prove the opposite correct?
> If there is even one, then it would prove the
> opposite correct?
Are you trying to be metaphysical? -:)
It's in fact quite trivial to find examples of non-concurrent real-time applications. Just about anything with one input would do, like for example a PID regulator in a control loop. BUT in this case we already know that the application is concurrent. It's given in the outset.
My point was that, because of the inherent parallelism of nature, any real-time concurrent application must be inherently concurrent (and not potentially concurrent) because the parallel processes are there and the application has no choise but to deal with them (that's 1 in my post #7).
> > If there is even one, then it would prove the
> > opposite correct?
>
> Are you trying to be metaphysical? -:)
>
> It's in fact quite trivial to find examples of
> non-concurrent real-time applications. Just about
> anything with one input would do, like for example a
> PID regulator in a control loop. BUT in this case we
> already know that the application is concurrent. It's
> given in the outset.
>
> My point was that, because of the inherent
> parallelism of nature, any real-time concurrent
> application must be inherently concurrent (and not
> potentially concurrent) because the parallel
> processes are there and the application has no choise
> but to deal with them (that's 1 in my post #7).
The above confuses me.
Here is the question I see from the OP....
and why is a real -time system is inherently concurrent?
That question seems to suggest to me that it is not limited to a subset of real time systems but rather is addressing all real time systems.
And you suggested that there are real time systems that do not require concurrency (first paragraph above.) Thus the answer to the OP is that they are not because they are not always concurrent.
Other than that I accept your definitions for the subset of real time systems. And if that subset is what the OP wanted then your answer applies.
> Other than that I accept your definitions for the
> subset of real time systems. And if that subset is
> what the OP wanted then your answer applies.
I've assumed the OP wants to classify concurrent applications as either inherently or potentially concurrent. Non-concurrent applications (real-time or otherwise) aren't considered.
Well this would need a clarification from the OP.
> > Other than that I accept your definitions for the
> > subset of real time systems. And if that subset
> is
> > what the OP wanted then your answer applies.
>
> I've assumed the OP wants to classify concurrent
> applications as either inherently or potentially
> concurrent. Non-concurrent applications (real-time or
> otherwise) aren't considered.
>
> Well this would need a clarification from the OP.
that's exactly what the question is about...but it's interesting for me to know that there are some real-time non-concurrent Apps !
enway i was expecting by posting this question to have maximum feedback that would shade some light about this...and that's what i got :) thanks guys
and Merry christmas for those celebrating it :)
> >
> > Well this would need a clarification from the OP.
>
> that's exactly what the question is about...but it's
> interesting for me to know that there are some
> real-time non-concurrent Apps !
That really depends on what your specific definition of real time is.
I wouldn't be surprised if a number of people who create embedded controllers would object to my little blinker circuit board as being a real time system. Some might agree though.
> I wouldn't be surprised if a number of people who
> create embedded controllers would object to my little
> blinker circuit board as being a real time system.
> Some might agree though.
....and some may say it's neither until you decide whether you're going to introduce a time constraint for the blinker or not.
> > > Well this would need a clarification from the OP.
> >
> > that's exactly what the question is about...but it's
> > interesting for me to know that there are some
> > real-time non-concurrent Apps !
>
> That really depends on what your specific
> definition of real time is.
Is a realtime application also always concurrent? I've avoided this deeper question because I felt it wasn't instrumental to the question of inherent/potential concurrency.
I feel there's an element in concurrency in realtime applications because you're measuring something against time. It's hard to think of a definition of realtime where this doesn't hold. So if you consider time a process, present in the form of some clock, running in parallel with everything else, then any realtime system must be considered concurrent. There are always at least two processes running of which one is time itself.
>
> Is a realtime application also always concurrent?
> I've avoided this deeper question because I felt it
> wasn't instrumental to the question of
> inherent/potential concurrency.
>
> I feel there's an element in concurrency in realtime
> applications because you're measuring something
> against time. It's hard to think of a definition of
> realtime where this doesn't hold. So if you consider
> time a process, present in the form of some clock,
> running in parallel with everything else, then any
> realtime system must be considered concurrent. There
> are always at least two processes running of which
> one is time itself.
You are stretching there.
Based on that definition every CPU chip since the mid-70s used in any application is a real time system. After all they all have clocks.
And if that is the case then what isn't a real time system?
> You are stretching there.
>
> Based on that definition every CPU chip since the
> mid-70s used in any application is a real time
> system. After all they all have clocks.
>
> And if that is the case then what isn't a real time
> system?
As usual you define your system at a convinient level of abstraction. Just because any physical computer can be defined as a realtime system in principle doesn't mean you have to treat every application you run on it as such.
What I'm saying is that when you define a realtime constraint (at your chosen level of abstraction) you're introducing a timing process in an application. And by doing this you get at least two parallel processes and thus a concurrent system. This is true if you consider time a process.
