I'm starting this thread to avoid hi-jacking another thread.
We can and do multi thread on any and ALL single CPU processors.
THIS HAS BEEN TRUE SINCE THE 1950! AND UNIVAC.
Multi threading does not require multiple processors or cores!
Multi processing does not require multiple processors or cores!
All it means is saving where we are upto in one job/task and then moving on to some other task.
The speed of the CPU (Even when they ran at kilo hertz ) makes such that they appear to do many things at the same time. This is what is meant (At least in the university I got my IT degree from ) as multi threading.
The same trick is used to do multi processing which, also, does not require multiple processors!
Just be cause the Thread class is not used and not supported by/on the arduinos does not mean that they do not multi thread.
What Robin2 shows in his "how to do more than one thing at a time" post IS MULTI THREADING.
Usually what we (I) refer to as multi-threading as multiple tasks being executed concurrently within the same process sharing same address space, and multi-tasking as multiple instances of programs that are under execution, with different address spaces (possibly with different rights) are both the responsibility of the OS Scheduler which we don't have in our Arduino...
here we need to code the Scheduler within our apps for multi-threading and it's hard to claim we can do multi-tasking
In both multi threading/ multi processing we create the illusion of doing more that one thing at a time thats where they both start from
Multi processing allows a single CPU with a single core to run many programs at the "same time" this was done to allow the best use to be made of an extremely expensive bit of kit.
Multi threading allows us to have a single program do many different things at the same time.
As the Thread classes are not supported we simply use an old school (1950) way of doing this.
Both Multi processing and multi threading use the same trick to create the illusion of doing more than one thing, allowing the speed of the computer to fool the slow slow human!
The trick is simple
we save where we where in one task/thread/process/job and
move on to the next one by picking up the saved context of the new task/job.......
The definition of multi threading for me is doing more than one thing at a time. And therefore we do multithread (if we wish - I'l ignore micros/mills etc)
Those who post questions about multi threading are looking for ways to do more than one thing at a time.
holmes4:
The definition of multi threading for me is doing more than one thing at a time.
I'm not a fan of personal definitions.
holmes4:
Those who post questions about multi threading are looking for ways to do more than one thing at a time.
I don't think that the inability of beginners to understand and use technical terms counts in any way.
holmes4:
So if I write the code to save the state
If you save the states of processor, stack and heap, I would call that multithreading,
if two functions use the same stack one after another I would not,
that would be just a normal program.
holmes4:
The definition of multi threading for me is doing more than one thing at a time.
I realize that these days people seem to feel they can make up their own "facts", but the true fact is, there are actual commonly-accepted definitions for the terms "multi-tasking", "multi-threading", and "multi-processing" among computer professionals, and your personal definitions do not matter. "Blink without delay" does not comply with the commonly-accepted definitions of ANY of the above terms. It is, instead, simply a very primitive, pseudo-multi-tasking. Even in the 1950s, FAR more sophisticated methods were used on time-sharing computers.
Regards,
Ray L.
RayLivingston:
I realize that these days people seem to feel they can make up their own "facts", but the true fact is, there are actual commonly-accepted definitions for the terms "multi-tasking", "multi-threading", and "multi-processing" among computer professionals, and your personal definitions do not matter. "Blink without delay" does not comply with the commonly-accepted definitions of ANY of the above terms
I have mixed feelings about this.
On the one hand I don't think it is helpful to a newbie to insulate him/her from commonly accepted technical definitions. It is generally not too difficult to explain that s/he is using an incorrect term.
On the other hand newbies come to us with the everyday stock of non-technical language and in that I reckon multi-tasking is close enough to BWoD and Several Things at a Time to make little difference. In common language a task is a job and that code gives the illusion that a number of jobs are being done at the same time.
And I don't consider it helpful to assume that a newbie is using a general term in a narrow technical sense without evidence - such as asking him/her what s/he means.
Multi-threading (on a single CPU) gives the exact same illusion - albeit with extra technical complexities that can have a lot of value in some circumstances.
I am assuming that multi-processing implies multiple CPUs in which case there is no illusion if the number of jobs does not exceed the number of CPUs.
if you have unix "roots" then a process and a thread are clear (different) animals.
So when you hear "multi-process" and "multi-thread", it's easy to interpret that in relation to what you know
if you have no computer science background, indeed a task, a process, a program are common language words - but I would say I did not come across newbies using the word "thread" to describe an activity. You start using this word when you've been exposed to some concepts (and know enough to put yourself in trouble)
Robin2:
On the one hand I don't think it is helpful to a newbie to insulate him/her from commonly accepted technical definitions. It is generally not too difficult to explain that s/he is using an incorrect term.
But it's ok to give then wrong definitions, just because it's easier? That's simply kicking the can down the road.
There are multi-tasking libraries for (some) Arduinos. So why not explain to them what they CAN do without the complexity those involve, and also explain to them how to get the same effect using BWD, WITHOUT mis-leading them about the true nature of BWD? This thread is simply spreading misleading, and technically incorrect, information.
Regards,
Ray L.
I was taught in the school that the 8086 (8088) appeared with the real capability of multi-tasking -- no illusion. Multi-tasking refers to a computing environment in which there is only one CPU (the 8086), and the CPU is doing many (bounded by the distribution of 1 MByte memory space) distinct tasks on round-robin schedule (simple task scheduling). To support real multi-tasking, a CPU must have segmented memory architecture which the 8086 possesses by virtue of four segment registers. In segmented architecture, every task has its own physical Code Segment Memory (to hold program code), Data Segment Memory (to hold data), Extra Segment Memory (to hold extra data), and Stack Segment Memory (to hold special data like PSW, Return Address, ...). When the CPU moves from one task to another, the complete states of the current task-1 (the contents of the Segment Registers, the PSW, and ...) are saved onto the Stack Segment Memory that belongs to the task-1 being exited.
Is this multi-tasking is same as the multi-processing/multi-threading being referred to in this thread?
