Printable View
Quote:
Originally posted by _uj
One weakness of C++ though is multithreading I think and that's why I engaged in this thread.
yes I missed your irony..probably because it wasn't ironic
:p
sorry where is c++ lacking in multithreading? heh heh...that's a trick question...because no lanquage is mutilthreading, what's that they say? it's the economy stupid? well it's the OS...
Yes I'm aware of this but when I looked at proposed additions to the C++ standard library I couldn't find anything about multithreading at all.Quote:
Originally posted by CornedBee
Boost contains the threading library, and one of the goals of Boost, as stated on their website, is to provide peer-reviewed libraries for eventual inclusion in the C++ standard.
and you won't. I thought I already said it, but it is not a lanquage that dictates multithreading, but an operating system. I can write an OS called FOO...and FOO does not support multithreading, and you say your going to provide a lanquage that will support multithreading on FOO?Quote:
Originally posted by _uj
Yes I'm aware of this but when I looked at proposed additions to the C++ standard library I couldn't find anything about multithreading at all.
Well, lets call it a draw then because I didn't found your comment very sarcastic.Quote:
Originally posted by Mick
yes I missed your irony..probably because it wasn't ironic
:p
I'm sorry to inform you that you're wrong. A programming language is a formal definition of an abstract computer. This abstract computer doesn't even have to exist in the form of real software and hardware. It's fully possible to introduce the concept of concurrency in a language, and it's done all the time, without even the slightest part of a OS in sight.Quote:
sorry where is c++ lacking in multithreading? heh heh...that's a trick question...because no lanquage is mutilthreading, what's that they say? it's the economy stupid? well it's the OS...
if you say so...Quote:
Originally posted by _uj
Well, lets call it a draw then because I didn't found your comment very sarcastic.
ahh I think you need to back up and rethink this. We are talking multi-threading are we not? careful now...Quote:
I'm sorry to inform you that you're wrong. A programming language is a formal definition of an abstract computer. This abstract computer doesn't even have to exist in the form of real software and hardware. It's fully possible to introduce the concept of concurrency in a language, and it's done all the time, without even the slightest part of a OS in sight.
A thread is just a line of execution. It can exist both as an abstraction at the language level and as a physical reality at the software/hardware level.Quote:
Originally posted by Mick
ahh I think you need to back up and rethink this. We are talking multi-threading are we not? careful now...
But I'm sure you have some other definition ready that once and for all will tell us what multi-threading really is about, so don't keep us waiting, just spill it.
First on the list is pre-emptive multitasking. Multiprocessing in 16-bit Windows is very noticeably inferior to multiprocessing in a system that supports pre-emptive multitasking, and pre-emptive multitasking requires that interrupts and such be processed.Quote:
Originally posted by _uj
But I'm sure you have some other definition ready that once and for all will tell us what multi-threading really is about, so don't keep us waiting, just spill it.
Related to that is asynchronous I/O. When doing I/O, if an operating system does nothing but wait for a read or write to complete (such as what DOS does) , then perfoarmance would be significantly degraded. Therefore to solve the problem the compiler would need to implement device I/O, which would be the equivalent of writing an OS.
hmm fantasy versus reality...which to choose....I guess since we are talking the abstract...I'm god...Quote:
Originally posted by _uj
Well, lets call it a draw then because I didn't found your comment very sarcastic.
I'm sorry to inform you that you're wrong. A programming language is a formal definition of an abstract computer. This abstract computer doesn't even have to exist in the form of real software and hardware. It's fully possible to introduce the concept of concurrency in a language, and it's done all the time, without even the slightest part of a OS in sight.
no it's the chicken and the egg here. Your comment said Java is multithreaded (or should I say you want the compiler/lanquage to dictate multithreading)...that's fine, but why is it multithreaded? Is it the lanquage or the operating system that makes it so? to write an OS you need a lanquage, to introduce multithreading in your OS you need to introduce multithreading in the underlying OS via the lanquage. Other lanquages can use this underlying support to say I'm multithreaded. But if you write an OS that doesn't support multithreading then whatever lanquages you have will not support multithreading, no matter how much they try. I think it's a pretty simple and clear concept...not sure what your point is.Quote:
Originally posted by _uj
A thread is just a line of execution. It can exist both as an abstraction at the language level and as a physical reality at the software/hardware level.
But I'm sure you have some other definition ready that once and for all will tell us what multi-threading really is about, so don't keep us waiting, just spill it.
Actually, that depends on the model of multithreading, U want to achive. There are a lot of realizations of thread libraries on the user-space level (1:M model). Of course, these threads are not full-functional, OS doesn't know anything about them, thus they have drawbacks, but still can be usefull for some cases.Quote:
Originally posted by Mick
But if you write an OS that doesn't support multithreading then whatever lanquages you have will not support multithreading, no matter how much they try.
dimmers...did you not just make my case? As I stated before, religious discussion...lets all say we differ in opinion and move on....Quote:
Originally posted by dimm_coder
Of course, these threads are not full-functional, OS doesn't know anything about them, thus they have drawbacks, but still can be usefull for some cases.
/And then we'll not take south carolina....yeaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa opps...
Yea. but I donot propose to place that kind of support in languages... but yea ..that's a religion.Quote:
Originally posted by Mick
dimmers...did you not just make my case? As I stated before, religious discussion...lets all say we differ in opinion and move on....
/ Imagine ... no religion too...
you can't imagine no religion without religion... :pQuote:
Originally posted by dimm_coder
/ Imagine ... no religion too...
/Imagine all the people...
Actually it's the virtual machine, so we'd best call it the OS.Quote:
Your comment said Java is multithreaded (or should I say you want the compiler/lanquage to dictate multithreading)...that's fine, but why is it multithreaded? Is it the lanquage or the operating system that makes it so?
Your "simple and clear concept" is just plain wrong. You don't need an OS with multithreading support for multithreading to exist in a programming language. That's my point and here's my reason why again:Quote:
Originally posted by Mick
...that's fine, but why is it multithreaded? Is it the lanquage or the operating system that makes it so?
I think it's a pretty simple and clear concept...not sure what your point is.
A programming language is a formal definition of an abstract computer. It's this abstract computer you think of when you program. You don't need an OS to think, do you? To actually run the program you'll need an implementation of the abstract computer in some combination of software and/or hardware but that's a different story.
It's when you fail to separate abstract concepts from possible implementations you end up with the kind of mishmash "theory" you presented.