multithreading has its uses. it can be used in a GUI to provide responsiveness. you can process jobs with it, windows has this concept already. here is a quick beginner's introduction.
find out number of cpu threads, number of available procs
find out number of cpu threads, number of available threads via std::thread? nope(10/15/2014).
there is no std::threads way of querying the number of procs. I wish there were. you could do better thread management that way. especially if you could find out how many available threads there are - then you could say "I need this percentage of those available threads because I want my process to be nice" or "I need this specific quantity of available threads".
Linux proc count
OSX proc count
Windows proc count
windows' thread jobs are a polling try-fail-try-again thing where you attempt to start a thread, and if it succeeds, great. if it doesn't you sleep for a while and try again. the sleep is so you don't chew up a proc/thread/core in the management thread, which blocks so the OS can do stuff with that cpu thread in the meantime if the that cpu thread is needed.
and there's mutexes, semaphores, and all sorts of locking semantics you can do for concurrency, with native threads, and possibly OpenMP.
there's the JS Web Workers multithreading API I haven't had much personal need to use it lately, but it looked useful for one web page I had that did the rain program type of thing, but you would quickly run out of CPU threads and didn't get it to run on ff at the time since it was a new API at the time, so I changed it to a timer event callback thing which works much better and handles more concurrency and is more fluid.
you can peg 100% cpu usage on a 1-thread proc and use up or slow down the whole machine by using a busy-wait with no Sleep() to block for the OS or other programs to use the thread. using a Sleep() in the loop would knock that way down, possibly to 1%.
if you do multithreading, you should buy a book or do some online reading on the subject, since there are complexities. for instance:
if 2 threads are concurrently accessing or alternately accessing a structure or variable, like the example of A and B threads both doing a read-increment-write, doing this without a semaphore or mutex can lose data - it should also be noted that semaphores (locks) can cause deadlock conditions, since the other threads are blocking (waiting) to access a single resource. in C/C++, you should declare it volatile at least (I think there are new std c++ lib declarations now possibly, but this is the only one I know of offhand, I forgot the new ones and have not looked into them in depth), so the compiler knows something might pop in an unexpectedly change the value.