Is a multi-threaded language property (like java) or an OS property?

Question

Is a multi-threaded language property (like java) or an OS property?

Answer 1

None. This is a property of the basic equipment. OS and languages ​​help us use the tools provided by the equipment.

Wiki can help: http://en.wikipedia.org/wiki/Multithreading

Answer 2

Multi-threading relies on hardware capabilities, but for most platforms, "hard work" is done by the OS. This is important, especially in modern multi-core systems. The OS also provides locking and monitoring capabilities.

Having said that, platforms appeared on which most of the multithreading capabilities, including scheduling and locking, are implemented on a virtual machine instead of the OS. They are known as Green Themes . However, they have limitations in multi-core systems and give way to natural OS streams in the most imperative languages.

There are other concurrency models that handle scheduling in the VM or at run time. They are usually found in functional languages, where the state is unchanged and, therefore, is not subject to the problems of blocking the joint altered state that we see in imperative languages. I think of Erlang and Haskell .

Answer 3

The programming model must have compatibility and / or memory model . For example, Java has threads and this memory model (a review on Wikipedia). This clearly refers to the semantics of the programming language, its specification.

Other programming languages ​​may have other concurrency abstractions (think of clojure with agents, etc.) or a different memory model. The simpler the memory model, the easier it is to use the language. Conversely, a complex memory model makes concurrency quite difficult to do correctly (think of the definition of volatile in Java). Therefore, some people argue that programming languages ​​should not have memory models.

Actual implementation The concurrency and / or memory model depends on the language performer. You can use the process / thread of the OS , or the VM can emulate threads (the so-called green thread ). There is even another approach to ultralight flows , for example Kilim .

However, in order to actually use multi-core , you must use OS threads (one per core), otherwise parallelism hardware. But the "logical" threads used by the program can be scheduled in an easy way in threads of the N OS. As far as I know, it is impossible to tell the JVM how many OS threads to use for scheduling green threads. If anyone has a pointer to this, it would be interesting.

In short: multithreading is a logical concept. An application can be multithreaded, but run on a single core. Multicore parallelism is a hardware concept. To use mutlicore parallelism, a virtual machine must implement threads in order to use an OS process that will run on different cores.

EDIT

In fact, the Java thread and memory model is now described in a special JSR-133 specification instead of chapter 17 of the Java Language Specification. Additional Information on JSR-133 Frequently Asked Questions

Answer 4

To add to the above points, when we say how many threads can be executed simultaneously? Then it depends on the processor as a dual-core and currently quad-core. Thus, each processor has the potential to simultaneously start a thread. It depends on the equipment. I hope my understanding is correct and the other members will correct me if I am wrong.

Answer 5

Ultimately, this is a hardware feature. Java had streaming capabilities from the start, but they were significantly more useful when introducing java.util.concurrent packages.

A real multithreading utility is useful for modern equipment that allows multiple threads. In older hardware, I / O operations can be understood and controlled by using a separate thread that can be blocked while waiting for data.