1
$\begingroup$

I've a couple of questions that I need answers for. What I am looking for here is the outline of the answers. Not necessarily the exact complete answer. I can do that. The question is that common operating systems provide support for concurrency through processes and threads.

There are differences between processes and threads and that well documented and easily understood. The issue here is What support does the hardware need to provide for processes and threads? The initial guess that came to my mind was that it is related to process communication and synchronization. However, these concepts are parts from another question which gets me to think that they are not the right answer. I am aware of the hyper-threading which is a hardware approach for concurrency. Is it ?!

The other question is that Operating systems and programming languages offer various means for communication and synchronization between processes and threads. What are the most common ones? What support does the hardware need to provide and, in particular, what instructions does a processor need to offer for communication and synchronization?

I know it is a long question but again, I don't seem to figure out the outline for the specific hardware support for (concurrent process and threads, as well as communication and synchronization).

Your help is highly appropriated

Improve this question
$\endgroup$
1
  • $\begingroup$ A distinction can be made between what is necessary and what is convenient (particularly with respect to portability w.r.t. timing factors). Hyperthreading is virtualized multiprocessing--i.e., a single physical processor/core looks to software like more than one. MIPS' MT-ASE provides a distinction between a thread context and a virtual processing element (and a physical processor/core). $\endgroup$ – Paul A. Clayton Apr 28 '13 at 20:03
2
$\begingroup$

Preemptive multithreading is usually implemented by the operating system using timer interrupts. Everything else can be done in software. Even the timer interrupts aren't strictly necessary: in cooperative multithreading (what they had in Windows 3.1 and earlier and MacOS prior to MacOS X) the operating system would perform the thread switch whenever a thread did a system call (e.g. a file read or write.)

A process has an address space with one or more threads running in it. Address spaces typically require hardware support for page tables.

There is no hardware support required for synchronization or communication. Multiple threads in the same process communicate through the address space they share. Threads within the same process typically synchronize using mutexes and condition variables. Mutexes and condition variables can be implemented with load and store instructions. (For the most part. There are some processors that don't have sequentially consistent memory hardware, and for those the processor also needs to implement some kind of memory barrier instructions.) When a thread needs to wait for a long time it will put itself to sleep by calling into the operating system.

Threads in different processes typically communicate through one of the abstractions implemented by the operating system (pipes, files, sockets).

Improve this answer
$\endgroup$
1
  • $\begingroup$ A process is more distinguished as having a separate protection domain. In a Single Address Space OS, processes do not have distinct address spaces and can communicate conveniently through memory addresses (traditional OSes can have special shared memory functionality). Simple loads and stores also introduce race conditions even with sequential consistency (e.g., two threads might--albeit with low probability barring interrupts--both read a lock as "unlocked" and claim the lock). A minimum of an atomic w.r.t. threads load+store (e.g., test-and-set) is very helpful. $\endgroup$ – Paul A. Clayton Apr 28 '13 at 19:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.