views:

230

answers:

5

Is multi-threading a property of a language (like java) or a property of OS?

+5  A: 

Neither. It is a property of the underlying hardware. OS and languages helps us to utilize the facility provided by the hardware.

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

bdhar
Multi threading can (and does) exist without the help of hardware (well, as long the hardware provides a timer interrupt at least)
Dean Harding
Yes. But it depends on the hardware. If there is no multithreading support, even if we use the API provided by the language, there will be no positive outcome. So, per OP's question, multithreading is a "property" of the harware and just the support is provided by OS and Java (or similar other languages).
bdhar
+1, but language/library support does help.
Robert Harvey
underlying hardware being a timer interrupt is not much compared to the amount of work needed on top of that to make a good multi threading environment.
Thorbjørn Ravn Andersen
The threading and memory model is clearly part of the semantics of the programming language. How it is implemented is another story.
ewernli
+4  A: 

Multi-threading does rely on hardware capabilities, but for most platforms the "heavy lifting" is done by the OS. This is essential, especially with modern multi-core systems. The OS also provide locking and monitoring capabilities.

Having said this, there have been platforms where a lot of the multi-threading capabilities, including scheduling and locking, are implemented in the virtual machine instead of the OS. These are known as Green Threads. However these have limitations in multi-core systems and are giving way to native OS threads in most imperative languages.

There are other concurrency models that handle the scheduling in the VM or runtime. These are typically in functional languages where state is immutable and therefore not susceptible to the locking issues of shared mutable state that we see in imperative languages. I'm thinking of Erlang and Haskell.

dsmith
A: 

To add to the above points,when we say how many threads can be run simultaneously? Then it depends on the processor like whether it is dual core and nowadays quad core.Thus each processor have a potential to run a thread simultaneously.Hence it is hardware dependent thing. I hope my understanding is correct and other members correct me if i am wrong.

Shashank T
Depends what you mean by 'run simultaneously'. Threads were around before multicore systems and they were still tremendously useful.
CurtainDog
A: 

Ultimately it is a property of the hardware. Java has had threading capabilities from the beginning, but these have been made much more usable with the introduction of the java.util.concurrent packages.

Real mulltithreading is useful on modern hardware that allows for multiple threads to be executed. On older hardware especially I/O operations can be easier to understand and control when using a seperate thread that can be blocked while waiting for data.

Jeroen van Bergen
+1  A: 

A programming model must have concurency and/or memory model. For instance Java has threads and this memory model (overview in wikipedia). This clearly belongs to the semantics of the programming language, its specification.

Other programming language may have other concurrency abstractions (think of clojure with agents, etc.) or other memory model. The simpler the memory model is, the simpler the language is to use. Inversly, a complicated memory model makes concurrency pretty hard to do right (think of the definition of volatile in Java). So some people argue that programming languages should have no memory model.

The actual implementation of the concurrency and/or memory model is up to the implementer of the language. You can use OS process/thread, or the VM can emulate threads (so-called green thread). There are even other approach to have ultra-light threads, for instance Kilim.

However, to really leverage multicore, you must OS threads (one per core), otherwise there is not hardware parallelism. But the "logical" threads used by the program can be scheduled in a lightweight fashion on the N OS threads. To my knowledge, it is not possible to tell the JVM how many OS threads to use to schedule the green threads. If somebody has a pointer for that, it would be interesting.

In summary: Multi-threading is a logical concept. An application can be multi-threaded but run on one core. Multicore parallelism is a hardware concept. To leverage mutlicore parallelism, the VM must implement threading so that OS process are used, which will run on different core.

EDIT

Actually the Java threading and memory model is now described in a dedicated specification JSR-133, instead of Chapter 17 of the Java Language Specification. More info on JSR-133 FAQ

ewernli