1

I have seen in some posts it has been said that to use multiple cores of processor use Boost thread (use multi-threading) library. Usually threads are not visible to operating system. So how can we sure that multi-threading will support usage of multi-cores. Is there a difference between Java threads and Boost threads?

Community
  • 1
  • 1
Lahiru
  • 2,609
  • 3
  • 18
  • 29
  • The operating system is the sole provider of preemptive threads. Boost merely wraps POSIX. The difference between Java and Boost is language; they are supposed to accomplish the same goal. – Potatoswatter Mar 03 '14 at 04:05
  • 4
    `Usually threads are not visible to operating system` not sure where you came up with that idea... – Ed S. Mar 03 '14 at 04:05
  • 1
    "Usually threads are not visible to operating system" --- not really. Look up "green threads" vs "native threads". Not all threads are green. – n. m. could be an AI Mar 03 '14 at 04:06
  • threads are parts which are running inside a process. Operating system can only see processes. Not details inside the processes. Then how can OS can support multi-threading? In java I have tried multi-threading programs and only one thread was running at a time. – Lahiru Mar 03 '14 at 04:09
  • 2
    Please avoid putting every other word between backticks. – R. Martinho Fernandes Mar 03 '14 at 05:59

1 Answers1

4

The operating system is also called a "supervisor" because it has access to everything. Since it is responsible for managing preemptive threads, it knows exactly how many a process has, and can inspect what they are doing at any time.

Java may add a layer of indirection (green threads) to make many threads look like one, depending on JVM and configuration. Boost does not do this, but instead only wraps the POSIX interface which usually communicates directly with the OS kernel.

Massively multithreaded applications may benefit from coalescing threads, so that the number of ready-to-run threads matches the number of logical CPU cores. Reducing everything to one thread may be going too far, though :v) and @Voo says that green threads are only a legacy technology. A good JVM should support true multithreading; check your configuration options. On the C++ side, there are libraries like Intel TBB and Apple GCD to help manage parallelism.

Potatoswatter
  • 134,909
  • 25
  • 265
  • 421
  • thank you for the answer. Are Intel TBB and Apple GCD hardware dependent? If so, do I have to do coding depending on the hardware platform?Is there any way to use parallel processing hardware independently(any built-in library for C/C++)? – Lahiru Mar 03 '14 at 04:43
  • 1
    @Lahiru Intel TBB is reasonably cross-platform; I haven't used it but it should support Windows, Mac, and mainstream Linuxes at least. I don't suppose they optimize it for AMD chips but it should be fine. Apple GCD is Mac-only (well, Darwin-only but non-Mac Darwin is dead AFAIK) and requires you to compile with Objective C. – Potatoswatter Mar 03 '14 at 04:51
  • Lahiru to add to @Potatoswatter's excellent answer it's worth pointing out that the architectures of modern multicore CPUs are heavily influenced by the need to support multithreaded processes. Threads as we know them require an SMP hardware architecture, and that has lead to complicated things like QPI and Hypertransport. Without the need to support SMP modern CPUs would be closer to Transputers in architecture. As it is they 'fake' SMP because they're now really NUMA under the hood. QPI and HyperTransport are very clever! – bazza Mar 03 '14 at 05:48
  • The reason for green threads was pretty much just simplicity and to avoid platform dependent behavior. No production JVM has used green threads for much over a decade - performance wise it was never a win. You'd have to go quite out of your way to find a JVM these days that even supports them. – Voo Mar 03 '14 at 16:04
  • @Voo Then it sounds like if a JVM does its own thread pooling to support massive multithreading, a la TBB, that would not be called "green threads." Is it more likely this is what OP encountered, or is it just a mystery? – Potatoswatter Mar 04 '14 at 02:07
  • @Potatoswatter The standard library does offer things like thread pools, fork/join frameworks, etc. for these kind of high-level things. But if you write `new Thread(...).start()` these days on any production JVM (also most research JVMs I'm aware of) you will get a native thread. If you do it 10k times you'll end up with 10k threads and bad performance. He may have misread something or misconfigured his OS or actually have been running on a single core VM/machine - many possibilities. – Voo Mar 04 '14 at 11:04