Few questions about concurrency

[Russel Winder via Digitalmars-d-learn]

On Sat, 2016-08-27 at 07:30 +0000, Suliman via Digitalmars-d-learn
wrote:
> […]
> 
> 1. There is OS threads. Context-switching is very expensive 
> because during it we should to save ALL CPU registers to RAM. 
> Accessing to RAM is slowly up 200-300 times then accessing to 
> registers, so dumping/restoring registers take a lot of time. 
> Right?

Without an explicit context there is no data and so phrases such as
"very expensive" are meaningless. Switching between kernel threads at
the operating system level is more expensive than performing an add
operation, but cheap compared to an IO operation. Of course if you have
8 processors then this changes everything compared to one processor.
Windows, Linux, AIX, OSX, all of which have subtly different concepts
of kernel thread, and which OS makes a difference to all the relative
costs. 

> 1.1 During context-switching OS is go to kernel-mode (ring-0). I 
> have heard opinion that it's cost a lot, but can't understand is 
> it true and why it cost a lot?

Context switching is (assuming the language hasn't changed in the last
40 years) usually about process switching which interrelates with
kernel thread switching (which is not the same thing), and binding of
threads to processor in a multiprocessor context. Most people using a
thread pool and avoiding explicit use of kernel threads are shielded
form all this at the expense of losing a little bit of control.

> 2. Message passing is superstructure of threads. Right? When it 
> can be helpful? Any user-case please.

It is not clear that this question is actually well formed: threads are
simply a context for execution of code 

> 2.1 Can simple threads pass data/messages to each other without 
> message passing?

Yes, and no. In kernel mode threads can stomp on whatever memory they
want in many operating systems, but not all of them, cf. microkernels.
In user mode threads are executing a process. Processes can only
communicate using the OS provided inter-process communication, which is
effectively message passing since it is mediated (usually) via queues
inside the kernel. Or via messages in a microkernel.

A quick search via google using the terms "message passing at kernel or
hardware level" provides a number of good pages which mostly contain
good stuff.  Sadly the Transputer and it's programming language Occam
do not seem to make an appearance without digging hard.

> 3. Fibers is threads that works in user-mode (rather in single 
> kernel-thread OS do not see them, it see only 1 own Thread).

On the humour front: fibres are what threads were before hardware made
threads what they are today.

Personally I prefer the tasks on a thread pool approach rather than a
fibres in a single thread one, but this is probably a moot point.

> 3.1 Fibers are switch explicitly. If do not call yield 
> mother-thread will be hang on.
> 3.2 Where fibers store CPU register state in moment of switching 
> between fibers? In memory? But then what difference with 
> context-switching (that take a lot of time to save/restore 
> registers state)?

Fibres have to store the CPU state yes, but that is part of the fibre
infrastructure and not something code using fibres should worry about.
No different from kernel threads really. Interesting how I still do not
think of threads as kernel threads unless I say kernel threads. Also
there are fibre systems and fibre systems. Some use explicit yield,
some implement timeouts and context switching. 

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20160828/da26f174/attachment.sig>