Does Raspberry support MultiThreading?

[marwan90]

Hello ,

Does the processor that Raspberry pi is equipped with support multi threading?

Thanks.

[tufty]

Multithreading is a software issue, not a hardware one.

In short, yes.

[gordon@drogon.net]

tufty said:


Multithreading is a software issue, not a hardware one.

In short, yes.



Oh, I don't know... I did a lot of stuff with transputers way back - they did a form of multi threading in hardware... (one core though)

However..

But yes, Linux is a multi-tasking operating system and as well as multiple 'tasks' (processes), it supports Posix threads.

Gordon

[Jim Manley]

The CPU in the Pi supports parallel execution of floating-point related instructions, but, not full hardware multithreading for all CPU instructions.  Linux, of course, supports software multithreading.  The major difference between the two is that hardware multithreading allows execution of more than one instruction pipeline in parallel, while software multithreading is limited to execution of only one instruction sequence at a time, and there is a time penalty each time the thread context is switched.  That penalty is not incurred with hardware multithreading – it happens at the beginning of the next clock cycle, IIRC (e.g., when a hardware interrupt occurs during the current clock cycle).

[rmm200]

A big part of a multitasking operating system is context switching. It is used in the servicing of interrupts, as well as giving control to a different task.

Context switching can be all software, or hardware assisted. The I386 and successor families have special hardware to support context switching. I do not know if the ARM processor has any hardware support in this area or not.

Wikipedia - as usual - has a decent discussion of the principles:

http://en.wikipedia.org/wiki/C.....ext_switch

[rurwin]

All very interesting, but we got along very nicely for decades without hardware support.

The answer is yes; Linux fully supports multi-threading.

[peterpi]

marwan90; If you will be programming in Python, see http://docs.python.org/library.....ading.html

If you will be programming in Java, see any of the documentation available.  It'll be exactly the same on the Pi as on anything else.

If you will be programming in C, then look for documentation on 'pthread' (http://en.wikipedia.org/wiki/P.....IX_Threads is a good starting point).  This is the same as Linux on e.g. your PC, and the same as other Unixes.

If you will be programming in C++ then use either pthread (just like in C) or alternatively use Boost::Thread, which is object oriented and cross platform (i.e. the same code will compile and run Windows*)

* (Yes, yes, I know about Cygwin et cetera.  I'm keeping it simple).

[jamesh]

rurwin said:


All very interesting, but we got along very nicely for decades without hardware support.

The answer is yes; Linux fully supports multi-threading.



You do need specific CPU instructions to get proper multitasking to work (test and set for example?), so in some ways, you always need HW support. I tried making a 68000 do simple multitasking once, but it just didn't have the right instructions to make it work, I think the 68020 fixed that. My memory could be faulty though. It was a long time ago.

[teh_orph]

James:

With the test-and-set example, you could always just turn off interrupts around your critical section if your CPU lacks atomic instructions...?

(to be fair though I think everything you would want to code for nowadays supports atomics!)

[rurwin]

I've run Unix on a 68000, I've run Xenix on an 80286, and I've done multi-tasking on a 6502 -- even on a BBC Micro. It's hard work and not really worth it on the 6502, but it is possible. As teh_orph says, all you need to do is disable interrupts. The only things that can break that are multiple processors, which the RaspPi does not have, and a non-maskable interrupt, which should not be doing anything to interfere with the thread context.

[Bakul Shah]

JamesH said:


You do need specific CPU instructions to get proper multitasking to work (test and set for example?), so in some ways, you always need HW support. I tried making a 68000 do simple multitasking once, but it just didn't have the right instructions to make it work, I think the 68020 fixed that. My memory could be faulty though. It was a long time ago.


The only issue with the original 68k was that you couldn't implement virtual memory because it did not save enough state to restart an instruction that failed due to a memory access error. This was fixed in 68010. But multitasking was not a problem. For a context switch all you need to do is to save the old thread's register state and restore the new thread's register state. A unix process has its own address space + one or more threads so for a process context switch you also have to save the virtual->physical memory mapping. There was no onchip MMU so one implemented an external MMU and had to save/restore its state for a process context switch.

[teh_orph]

I remember learning about 68000 virtual memory at uni and at the time my mind was boggled!

Since it couldn't restart instructions some vendors ran two 68000s on a board, with one CPU one clock cycle ahead of the other. Using some smarts they could use the first CPU to guide what the second CPU should do on a fault! Weird stuff.

Applause for the engineers please!

http://en.wikipedia.org/wiki/A.......n#Models

[plugwash]

JamesH said:


You do need specific CPU instructions to get proper multitasking to work (test and set for example?),


You don't "need" atomic instructions, they just help you do things more efficiently and/or securely. Without them you pretty much have to disable interrupts to implement syncronisation primitives.

The problem then becomes if you let userland code disable interrupts then any process can freeze the system if it disables intterups and doesn't reenable them. If you don't let userland code disable interrupts then you incur the cost of a system call for every operation that requires them to be disabled.

rurwin said:


It's hard work and not really worth it on the 6502, but it is possible.


Afaict the big problem on the 6502 is that the stack can only live in page 1. Typically 6502 based systems have page 1 directly mapped to ram with no bank switching. So you would end up having very small stack sections for each task or copying the stack on every context switch.

I think with the right bank switching system (you would want some of pages 0 and 1 to be fix mapped for the OS and some of pages 0 and 1 to be banked for the applications) you could multitask pretty effectively on a 6502.

[jamesh]

Bakul said:


JamesH said:


You do need specific CPU instructions to get proper multitasking to work (test and set for example?), so in some ways, you always need HW support. I tried making a 68000 do simple multitasking once, but it just didn't have the right instructions to make it work, I think the 68020 fixed that. My memory could be faulty though. It was a long time ago.


The only issue with the original 68k was that you couldn't implement virtual memory because it did not save enough state to restart an instruction that failed due to a memory access error. This was fixed in 68010. But multitasking was not a problem. For a context switch all you need to do is to save the old thread's register state and restore the new thread's register state. A unix process has its own address space + one or more threads so for a process context switch you also have to save the virtual->physical memory mapping. There was no onchip MMU so one implemented an external MMU and had to save/restore its state for a process context switch.


I think that might be what I was thinking of - I did say it was a long time ago!

[lineover]

The CPU in the Pi supports parallel execution of floating-point related instructions, [...] more than one instruction pipeline in parallel

being curious now, how many pipelines we got available?

[AndrewS]

being curious now, how many pipelines we got available?

Dunno myself, but http://elinux.org/RPi_Hardware has links to all the relevant datasheets

[Gert van Loo]

The CPU in the Pi supports parallel execution of floating-point related instructions, [...] more than one instruction pipeline in parallel

being curious now, how many pipelines we got available?

I think about nineteen.

[poiqwepoi]

http://researchlair.com/?p=14