Java runtime intranet installation? [found it, sort of]
-
So, is this[^] the only way to obtain a Java runtime installation package, that doesn't require Internet connectivity? :sigh: Why, oh why, is this so difficult? [edit] I found this[^] link (as Rohde also pointed out) but I can't figure out how to get there from the home page unless Java is not actually already installed. I'm trying really hard here not to criticize the general "we hate Microsoft" community, but this is so friggin' typical of these sites. [/edit] Marc -- modified at 11:17 Monday 2nd July, 2007
Marc Clifton wrote:
I can't figure out how to get there from the home page unless Java is not actually already installed.
It's the first Google search result for "jre download" :rolleyes: I always keep a copy of the offline installer so I don't have to keep re-downloading the damn thing so I wasn't aware there was any other kind.
I enjoy occasionally wandering around randomly, and often find that when I do so, I get to where I wanted to be [^]. Awasu 2.3 [^]: A free RSS/Atom feed reader with support for Code Project. 50% discount on the paid editions for CP members!
-
Rohde wrote:
but it's still a waste of my time doing manuel memory management if I don't really need the speed it buys me - it's more useful spending time domain programming/modelling. But hey I guess some of you need the ego boost you get from new/delete/RAII and other idioms.
Ah.... you are a true visionary :rolleyes: The free lunch is OVER script kiddies days are numbered :-D :jig: :jig: :-D
led mike wrote:
The free lunch is OVER script kiddies days are numbere
I agree. Multi-threaded development is the next "hurdle" for us, and the last couple of years with threaded programming in especially Java and C# has shown that it is way more complex than first envisioned. Many people are really underestimating the difficulties of multi threaded programming - this was also evident in the Java 5 release where the thread model was totally revamped. And it is a disaster that we are still waiting for support for multi threaded programming in the C++ standard library.
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn Rand -
led mike wrote:
The free lunch is OVER script kiddies days are numbere
I agree. Multi-threaded development is the next "hurdle" for us, and the last couple of years with threaded programming in especially Java and C# has shown that it is way more complex than first envisioned. Many people are really underestimating the difficulties of multi threaded programming - this was also evident in the Java 5 release where the thread model was totally revamped. And it is a disaster that we are still waiting for support for multi threaded programming in the C++ standard library.
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn RandRohde wrote:
And it is a disaster that we are still waiting for support for multi threaded programming in the C++ standard library.
are you also waiting for 3D/4D graphics support in the C++ standard library? stereo sound, perhaps even 7.1 stereo sound? I know it would be nice to have the language do everything for you, but it isn't going to happen. When you try to make everything too easy, you get code bloat from the complexity internal to making it easier. This is actually why the problems with Java. OpenMP has been around for a long time, and is available on most platforms, if you don't want that, there are Operating system level threading. Everything is there for threading right now. But there is no magic bullet that will *poof* make all your software automatically massively parallel, efficient, and never worry about reentrancy. Yes, I think the C++ standard library should focus on rentrant code, I think all libraries should -- we've seen the end of the single core. But there will ever be a point where you end up going to a 3rd party library or a platform specific one, because there is always something new. OpenMP is one of the easier methods of multi-threaded programming, it seems complex because it has so many options. But that is the point, you can parallelize a for loop to many cores, and/or run asynchronous threads, choice allows you the power to parallelize efficiently once you learn the tools. If you are waiting for everyone to do that learning for you and then offer you a magical construct that self-parallelizes your code, you have a very long wait.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
So, is this[^] the only way to obtain a Java runtime installation package, that doesn't require Internet connectivity? :sigh: Why, oh why, is this so difficult? [edit] I found this[^] link (as Rohde also pointed out) but I can't figure out how to get there from the home page unless Java is not actually already installed. I'm trying really hard here not to criticize the general "we hate Microsoft" community, but this is so friggin' typical of these sites. [/edit] Marc -- modified at 11:17 Monday 2nd July, 2007
:laugh: Do either of these shortcuts help Marc? Online version: http://javadl.sun.com/webapps/download/AutoDL?BundleId=11145[^] Offline version: http://javadl.sun.com/webapps/download/AutoDL?BundleId=11193[^]
Ant. I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Walliams (Little Britain) -
Rohde wrote:
And it is a disaster that we are still waiting for support for multi threaded programming in the C++ standard library.
are you also waiting for 3D/4D graphics support in the C++ standard library? stereo sound, perhaps even 7.1 stereo sound? I know it would be nice to have the language do everything for you, but it isn't going to happen. When you try to make everything too easy, you get code bloat from the complexity internal to making it easier. This is actually why the problems with Java. OpenMP has been around for a long time, and is available on most platforms, if you don't want that, there are Operating system level threading. Everything is there for threading right now. But there is no magic bullet that will *poof* make all your software automatically massively parallel, efficient, and never worry about reentrancy. Yes, I think the C++ standard library should focus on rentrant code, I think all libraries should -- we've seen the end of the single core. But there will ever be a point where you end up going to a 3rd party library or a platform specific one, because there is always something new. OpenMP is one of the easier methods of multi-threaded programming, it seems complex because it has so many options. But that is the point, you can parallelize a for loop to many cores, and/or run asynchronous threads, choice allows you the power to parallelize efficiently once you learn the tools. If you are waiting for everyone to do that learning for you and then offer you a magical construct that self-parallelizes your code, you have a very long wait.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
You do know that threading will be part of C++0x, right? This is not about "everyone to do that learning for me" but about C++ having support for threading built in. Pretty much everybody on the C++ committee agree that the lack of threading support is a major problem for C++. But hey, why don't we just code in assembler?
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn Rand -
You do know that threading will be part of C++0x, right? This is not about "everyone to do that learning for me" but about C++ having support for threading built in. Pretty much everybody on the C++ committee agree that the lack of threading support is a major problem for C++. But hey, why don't we just code in assembler?
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn RandRohde wrote:
But hey, why don't we just code in assembler?
You sure you aren't a Java programmer? :rolleyes: That comment sure sounds like one. Yes, "threading" will be part of C++, as in "asynchronous threads" without much support for additional constructs. Simple mutex will definately be there, they are still arguing over readwrite locks, and other mechanisms. But it will not be more than you have NOW, and probably much less than you have available NOW. I never stopped doing graphics because C++ committee had not standardized it into their library, nor did I ignore threading until forced to do so by multi-core. I've been parallel, even massively parallel from the sound of it, longer than you have been programming. Nothing beats learning. No one prevents you from learning how to do threading effectively, except YOU. The standards committee can argue until we all grow old, and if you are simply waiting for them before you learn to do threading right, I suggest you retire now. Programming is at the heart making the most out of what you have available, not passing the buck to a committee who take 10 years to agree on what you should have done yourself over the last 10 years.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Rohde wrote:
but it's still a waste of my time doing manuel memory management if I don't really need the speed it buys me - it's more useful spending time domain programming/modelling. But hey I guess some of you need the ego boost you get from new/delete/RAII and other idioms.
Ah.... you are a true visionary :rolleyes: The free lunch is OVER script kiddies days are numbered :-D :jig: :jig: :-D
led mike wrote:
The free lunch is OVER script kiddies days are numbered
Yeah right. As if there won't be a "processor core" set of libraries in .net framework. Give me a break.
I didn't get any requirements for the signature
-
led mike wrote:
The free lunch is OVER script kiddies days are numbere
I agree. Multi-threaded development is the next "hurdle" for us, and the last couple of years with threaded programming in especially Java and C# has shown that it is way more complex than first envisioned. Many people are really underestimating the difficulties of multi threaded programming - this was also evident in the Java 5 release where the thread model was totally revamped. And it is a disaster that we are still waiting for support for multi threaded programming in the C++ standard library.
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn RandRohde wrote:
and the last couple of years with threaded programming in especially Java and C# has shown that it is way more complex than first envisioned.
I've been doing mult-threaded development since 1995. I never envisioned it as anything but complex. That is probably because I "read about it first, studied it first" before I started writing anything. Someone here on CP once posted a reply to the question "what is the difference between a programmer and a software engineer". He said something like: "At the start of a project the first thing a programmer does is write code. The first thing an engineer does is think."
Rohde wrote:
Many people are really underestimating the difficulties of multi threaded programming
any and all aspects of software development. They are Script Kiddies, also known as VBers.
-
Rohde wrote:
But hey, why don't we just code in assembler?
You sure you aren't a Java programmer? :rolleyes: That comment sure sounds like one. Yes, "threading" will be part of C++, as in "asynchronous threads" without much support for additional constructs. Simple mutex will definately be there, they are still arguing over readwrite locks, and other mechanisms. But it will not be more than you have NOW, and probably much less than you have available NOW. I never stopped doing graphics because C++ committee had not standardized it into their library, nor did I ignore threading until forced to do so by multi-core. I've been parallel, even massively parallel from the sound of it, longer than you have been programming. Nothing beats learning. No one prevents you from learning how to do threading effectively, except YOU. The standards committee can argue until we all grow old, and if you are simply waiting for them before you learn to do threading right, I suggest you retire now. Programming is at the heart making the most out of what you have available, not passing the buck to a committee who take 10 years to agree on what you should have done yourself over the last 10 years.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
El Corazon wrote:
You sure you aren't a Java programmer?
I'm sure. But on the other hand I'm not too proud to stand on the shoulders of giants.
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn Rand -
Marc Clifton wrote:
I can't figure out how to get there from the home page unless Java is not actually already installed.
It's the first Google search result for "jre download" :rolleyes: I always keep a copy of the offline installer so I don't have to keep re-downloading the damn thing so I wasn't aware there was any other kind.
I enjoy occasionally wandering around randomly, and often find that when I do so, I get to where I wanted to be [^]. Awasu 2.3 [^]: A free RSS/Atom feed reader with support for Code Project. 50% discount on the paid editions for CP members!
Taka Muraoka wrote:
It's the first Google search result for "jre download"
Sigh. I guess I haven't had it hammered into me: the vendor's website is useless, use google to find what you want on the vendor's website.
Taka Muraoka wrote:
I always keep a copy of the offline installer so I don't have to keep re-downloading
That's what I was trying to do too. Marc
-
Rohde wrote:
and the last couple of years with threaded programming in especially Java and C# has shown that it is way more complex than first envisioned.
I've been doing mult-threaded development since 1995. I never envisioned it as anything but complex. That is probably because I "read about it first, studied it first" before I started writing anything. Someone here on CP once posted a reply to the question "what is the difference between a programmer and a software engineer". He said something like: "At the start of a project the first thing a programmer does is write code. The first thing an engineer does is think."
Rohde wrote:
Many people are really underestimating the difficulties of multi threaded programming
any and all aspects of software development. They are Script Kiddies, also known as VBers.
led mike wrote:
The first thing an engineer does is think
If only we had more of that!! :doh:
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Rohde wrote:
and the last couple of years with threaded programming in especially Java and C# has shown that it is way more complex than first envisioned.
I've been doing mult-threaded development since 1995. I never envisioned it as anything but complex. That is probably because I "read about it first, studied it first" before I started writing anything. Someone here on CP once posted a reply to the question "what is the difference between a programmer and a software engineer". He said something like: "At the start of a project the first thing a programmer does is write code. The first thing an engineer does is think."
Rohde wrote:
Many people are really underestimating the difficulties of multi threaded programming
any and all aspects of software development. They are Script Kiddies, also known as VBers.
led mike wrote:
I've been doing mult-threaded development since 1995. I never envisioned it as anything but complex.
thinking on this some more, I have a slight problem with this, but only slight, I think it is a matter of semantics and point-of-view. I don't look at threading as complex, though massively parallel can be at times, rather threading requires thought. You can get away with a lot of bad practices in single threads because it only executes one mistake at a time and all you loose is time. But when you parallelize your code, mistakes build upon mistakes. It is still easy to thread, but you can no longer program without thought. However, I still hear demands for compilers to parallelize people's code at GDC, and Intel reminds everyone that OpenMP has been there for nearly a decade now, but there is no magic bullet. You can always mutex() a mistake to lock it out from being executed in parallel and crashing your program, which again shows the differences in programming methodology. If you build it correctly, you minimize mutexes and atomic operations, but that requires thought and planning. Or you just start writing code, ignore thinking, and anywhere your program crashes in a thread you atomic() wrap it via C++0x or mutex() it, or something similar in your platform. Rather than fix it, you simply try to prevent it from crashing, because if it compiles, it is obviously "right" and bug free.... :(( If only we taught thinking to programmers now. :sigh:
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
led mike wrote:
The free lunch is OVER script kiddies days are numbere
I agree. Multi-threaded development is the next "hurdle" for us, and the last couple of years with threaded programming in especially Java and C# has shown that it is way more complex than first envisioned. Many people are really underestimating the difficulties of multi threaded programming - this was also evident in the Java 5 release where the thread model was totally revamped. And it is a disaster that we are still waiting for support for multi threaded programming in the C++ standard library.
"When you have made evil the means of survival, do not expect men to remain good. Do not expect them to stay moral and lose their lives for the purpose of becoming the fodder of the immoral. Do not expect them to produce, when production is punished and looting rewarded. Do not ask, `Who is destroying the world?' You are."
-Atlas Shrugged, Ayn RandRohde wrote:
Java and C# has shown that it is way more complex than first envisioned.
Seconded. Every time I hear someone say "Threaded programming is easy!" or "I know all about that threading stuff", I just cry a little inside. Large applications built on those peoples training is a scary sight to behold!
Rohde wrote:
this was also evident in the Java 5 release where the thread model was totally revamped.
Since moving to .Net in a serious way, probably the biggest thing I miss from Java land is the concurrency library. It was so much easier to think in terms of higher level constructs than to think in terms of semaphores and mutexes. I really miss it! I haven't noticed a few similar structures appearing, but I still have a soft spot in my heart of Java. - Phil
-
So, is this[^] the only way to obtain a Java runtime installation package, that doesn't require Internet connectivity? :sigh: Why, oh why, is this so difficult? [edit] I found this[^] link (as Rohde also pointed out) but I can't figure out how to get there from the home page unless Java is not actually already installed. I'm trying really hard here not to criticize the general "we hate Microsoft" community, but this is so friggin' typical of these sites. [/edit] Marc -- modified at 11:17 Monday 2nd July, 2007
-
led mike wrote:
I've been doing mult-threaded development since 1995. I never envisioned it as anything but complex.
thinking on this some more, I have a slight problem with this, but only slight, I think it is a matter of semantics and point-of-view. I don't look at threading as complex, though massively parallel can be at times, rather threading requires thought. You can get away with a lot of bad practices in single threads because it only executes one mistake at a time and all you loose is time. But when you parallelize your code, mistakes build upon mistakes. It is still easy to thread, but you can no longer program without thought. However, I still hear demands for compilers to parallelize people's code at GDC, and Intel reminds everyone that OpenMP has been there for nearly a decade now, but there is no magic bullet. You can always mutex() a mistake to lock it out from being executed in parallel and crashing your program, which again shows the differences in programming methodology. If you build it correctly, you minimize mutexes and atomic operations, but that requires thought and planning. Or you just start writing code, ignore thinking, and anywhere your program crashes in a thread you atomic() wrap it via C++0x or mutex() it, or something similar in your platform. Rather than fix it, you simply try to prevent it from crashing, because if it compiles, it is obviously "right" and bug free.... :(( If only we taught thinking to programmers now. :sigh:
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
I reckon you hit the nail right on the head as to where the real problem is. The requirement to thoroughly think through any problem requiring a multi threaded solution already places it orders of magnitude in difficult above what the 'average' programmer does. I'm not sure however that forcing everyone to think through at that fine grain level is necessarily the right way to go. Ideally, it would be the perfect solution, but more cost effective ways will emerge. Working with higher level constructs instead of the very error prone mutexes and semaphores, wait/notifies , I think will be part of the so called "magic bullet". If we can build our software with pieces that we know agree with concurrency, then we have a far better chance of building it correctly. - Phil
-
I reckon you hit the nail right on the head as to where the real problem is. The requirement to thoroughly think through any problem requiring a multi threaded solution already places it orders of magnitude in difficult above what the 'average' programmer does. I'm not sure however that forcing everyone to think through at that fine grain level is necessarily the right way to go. Ideally, it would be the perfect solution, but more cost effective ways will emerge. Working with higher level constructs instead of the very error prone mutexes and semaphores, wait/notifies , I think will be part of the so called "magic bullet". If we can build our software with pieces that we know agree with concurrency, then we have a far better chance of building it correctly. - Phil
Phil Martin... wrote:
Working with higher level constructs
except that the higher level constructs simply reduce everything to mutexed operations or fully open operations not allowing you the choice. You still end up with lock-stepped threads removing all performance benefit of your threading, except now you have no way to fix it. You can go higher and higher, but the net result is still the same, without thought, you have nothing. You do not have to have a fine grain analysis of mutexes and semaphores, you should know where to use them, and use them only there. You learn, through thought, what needs protection, what does not. Do you need a read-many, write once lock? no problem, use it. Do you really need a mutual exlusion lock, fine, then use it. The problem is not the low level construct, but the fact that programs are written without thought and then massive numbers of mutex and semaphores are added trial and error fashion until the code works. If you want higher-level, use a threaded class with all the controls built in, then reuse it. But you still have the low-grain control if you need it. Thought allows you to know when to use it, when not to.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Phil Martin... wrote:
Working with higher level constructs
except that the higher level constructs simply reduce everything to mutexed operations or fully open operations not allowing you the choice. You still end up with lock-stepped threads removing all performance benefit of your threading, except now you have no way to fix it. You can go higher and higher, but the net result is still the same, without thought, you have nothing. You do not have to have a fine grain analysis of mutexes and semaphores, you should know where to use them, and use them only there. You learn, through thought, what needs protection, what does not. Do you need a read-many, write once lock? no problem, use it. Do you really need a mutual exlusion lock, fine, then use it. The problem is not the low level construct, but the fact that programs are written without thought and then massive numbers of mutex and semaphores are added trial and error fashion until the code works. If you want higher-level, use a threaded class with all the controls built in, then reuse it. But you still have the low-grain control if you need it. Thought allows you to know when to use it, when not to.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
I agree with the thought process side of things, but not with the cost effectiveness of those low level tools to every situation. For the majority of work that I do, my time is better spent in fine tuning the areas that need it, rather than making sure every single lock operation I do is perfect. The problem with using them only where you need to, is that in complex systems it is very hard to judge correctly when you do and do not. And that is what I am getting at - if I can use some tools to that vastly reduce the risk of making mistakes, at the expense of some performance, then I'd be happy with that trade off. I'd much prefer a piece of software that runs at 80% efficiency, rather than one at 100% efficiency but 12 months late! But then again, maybe I just suck at concurrent programming. My ego tells me otherwise, but I just gotta shout that guy down some days :) - Phil
-
I agree with the thought process side of things, but not with the cost effectiveness of those low level tools to every situation. For the majority of work that I do, my time is better spent in fine tuning the areas that need it, rather than making sure every single lock operation I do is perfect. The problem with using them only where you need to, is that in complex systems it is very hard to judge correctly when you do and do not. And that is what I am getting at - if I can use some tools to that vastly reduce the risk of making mistakes, at the expense of some performance, then I'd be happy with that trade off. I'd much prefer a piece of software that runs at 80% efficiency, rather than one at 100% efficiency but 12 months late! But then again, maybe I just suck at concurrent programming. My ego tells me otherwise, but I just gotta shout that guy down some days :) - Phil
Phil Martin... wrote:
For the majority of work that I do, my time is better spent in fine tuning the areas that need it, rather than making sure every single lock operation I do is perfect.
My time is better suited elsewhere too, and is done so. I don't spend ages manipulating locks and low level constructs. People make it sound like it is programming assembly, it is not. But it is parallel thought. Everything can happen simultaneously, so thought goes in: Can A occur when B is running? yes. Can B occur while A is running? yes. Will C work with A and B? yes. and so on and so forth. The idea that all operations are asynchronous and anything can happen at any time requires some thought, but we are not talking about writing war&peace, we're not even talking about nobel prize material here. It is simply a change in thought. You do what is necessary to protect what is necessary, no more, no less. No one is asking for 100% efficiency and perfection, no one is asking you to rewrite all your code in assembly. Is it really that hard to think: readlock() code.... unlock() and writelock() code unlock() is that so mindboggling as to defy description and place unparalleled burden on the programmers? You said "thinking" is beyond what most programmers do. That is the most frightening think you have said. The idea that you can program without thought, without analysis, without planning, without a goal, without any form of functional guideline.... just pour out code and hope the compiler is smart/dumb enough to prevent you from making mistakes? It truly is a sad, sad day if that is the demands of programmers to allow themselves to do that.... it is no wonder programmers can't get over the concurrent hurdle, if thought is to prevented, if planning removed.... :((
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Phil Martin... wrote:
For the majority of work that I do, my time is better spent in fine tuning the areas that need it, rather than making sure every single lock operation I do is perfect.
My time is better suited elsewhere too, and is done so. I don't spend ages manipulating locks and low level constructs. People make it sound like it is programming assembly, it is not. But it is parallel thought. Everything can happen simultaneously, so thought goes in: Can A occur when B is running? yes. Can B occur while A is running? yes. Will C work with A and B? yes. and so on and so forth. The idea that all operations are asynchronous and anything can happen at any time requires some thought, but we are not talking about writing war&peace, we're not even talking about nobel prize material here. It is simply a change in thought. You do what is necessary to protect what is necessary, no more, no less. No one is asking for 100% efficiency and perfection, no one is asking you to rewrite all your code in assembly. Is it really that hard to think: readlock() code.... unlock() and writelock() code unlock() is that so mindboggling as to defy description and place unparalleled burden on the programmers? You said "thinking" is beyond what most programmers do. That is the most frightening think you have said. The idea that you can program without thought, without analysis, without planning, without a goal, without any form of functional guideline.... just pour out code and hope the compiler is smart/dumb enough to prevent you from making mistakes? It truly is a sad, sad day if that is the demands of programmers to allow themselves to do that.... it is no wonder programmers can't get over the concurrent hurdle, if thought is to prevented, if planning removed.... :((
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
El Corazon wrote:
Is it really that hard to think: readlock() code.... unlock() and writelock() code unlock() is that so mindboggling as to defy description and place unparalleled burden on the programmers?
Actually, yes, I think that is too hard. Way too hard. I'm sure we can both come up with scenarios where even that trivial scenario will fail in a multi processor environment. In complex systems even seemingly trivial scenarios become too complex to analyze correctly.
El Corazon wrote:
You said "thinking" is beyond what most programmers do. That is the most frightening think you have said. The idea that you can program without thought, without analysis, without planning, without a goal, without any form of functional guideline....
That would indeed be very very bad indeed. But what I actually said was
Phil Martin... wrote:
to thoroughly think through any problem requiring a multi threaded solution already places it orders of magnitude in difficult above what the 'average' programmer does
I am just saying that to corectly solve a multithreaded problem requires many many times more effort than a single threaded one.
El Corazon wrote:
just pour out code and hope the compiler is smart/dumb enough to prevent you from making mistakes?
No way. Wasn't suggeting it and never would. I want as much of my code to be formally correct before it even touches a compiler. Hence my advocacy for better, easier, and less error prone concurrency constructs.
El Corazon wrote:
It is simply a change in thought.
And I am in total agreement - the main ingredient required is a change in thought processes to tackle the future in concurrency. I just happen to think what we should be thinking about is different to what you think we should be thinking about :) - Phil
-
Phil Martin... wrote:
Working with higher level constructs
except that the higher level constructs simply reduce everything to mutexed operations or fully open operations not allowing you the choice. You still end up with lock-stepped threads removing all performance benefit of your threading, except now you have no way to fix it. You can go higher and higher, but the net result is still the same, without thought, you have nothing. You do not have to have a fine grain analysis of mutexes and semaphores, you should know where to use them, and use them only there. You learn, through thought, what needs protection, what does not. Do you need a read-many, write once lock? no problem, use it. Do you really need a mutual exlusion lock, fine, then use it. The problem is not the low level construct, but the fact that programs are written without thought and then massive numbers of mutex and semaphores are added trial and error fashion until the code works. If you want higher-level, use a threaded class with all the controls built in, then reuse it. But you still have the low-grain control if you need it. Thought allows you to know when to use it, when not to.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
How exactly do functional languages get compiled? AIUI the way they're built every operation is fundamentally atomic and independent and that they scale to N processor systems without requiring any code changes.
-- You have to explain to them [VB coders] what you mean by "typed". their first response is likely to be something like, "Of course my code is typed. Do you think i magically project it onto the screen with the power of my mind?" --- John Simmons / outlaw programmer