Java runtime intranet installation? [found it, sort of]
-
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
-
Ed.Poore wrote:
Um[^]? Check the first table.
Well, I was trying to find it visiting. www.java.com. I won't even bother with a clickety. Don't waste your time. Marc
-
Ed.Poore wrote:
Um[^]? Check the first table.
Well, I was trying to find it visiting. www.java.com. I won't even bother with a clickety. Don't waste your time. Marc
-
Ed.Poore wrote:
Um[^]? Check the first table.
Well, I was trying to find it visiting. www.java.com. I won't even bother with a clickety. Don't waste your time. Marc
Done it first visit, they must have been listening to you:
- Visit http://www.java.com[^]
- Click "Free Download"
- If pops up asking to install say no
- Under the first picture after "Not the right operating system?" click the "See all Java downloads here"
- Voila!
-
Done it first visit, they must have been listening to you:
- Visit http://www.java.com[^]
- Click "Free Download"
- If pops up asking to install say no
- Under the first picture after "Not the right operating system?" click the "See all Java downloads here"
- Voila!
Ed.Poore wrote:
If pops up asking to install say no
That step only appears if you don't have Java installed. If you do, it goes immediately to a "Verify Java" screen. So, if you don't, and you go ahead and install, thinking you'll get the option to save the installation to disk, you're screwed. :) Marc
-
Ed.Poore wrote:
If pops up asking to install say no
That step only appears if you don't have Java installed. If you do, it goes immediately to a "Verify Java" screen. So, if you don't, and you go ahead and install, thinking you'll get the option to save the installation to disk, you're screwed. :) Marc
-
Rohde 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
Phil Martin... wrote:
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 don't understand that. I did several years of work in Java back in 2000/2001 and I remember multi-threading seemed very similar to working with Win32 synchronization kernel objects of the same time period.
-
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
dan neely wrote:
is fundamentally atomic and independent and that they scale to N processor systems without requiring any code changes.
everything is independent, but not atomic. Atomic functionality provides the realism that this code must not be executed on any core/processor/thread other than one and only one at a time. It is the core of any multi-threaded operation. All lower level constructs must be atomic to prevent co-ownership. At the higher level compilers would take
atomic
{
code();
}and at the lower level
lock()
code();
unlock()These are functionally equivalent atomic operations for a given code() call. There is no automatic parallelizing function given that some loops do not scale well, you do not want to parallelize all loops or you get more problems. There is an auto-parallel option on the Intel compilers, however it rarely gains you as much performance as a bit of thought. for instance:
#pragma omp parallel for default(none) \
private(i,j,sum) shared(m,n,a,b,c)
for (i=0; i
looks complicated, but it tells the compiler which is shared variables, which are private, this allows the routine to be parallelized across N cores with minimal code-change, all it requires is a little upfront "though" on what is parallelizable. Auto-parallelize would simply skip the for-loop recognizing that it was beyond scope of the auto-parallelize, where-as:for (i=0; i
would auto-parallelize seeing only one major variable, and mostly constants. But that might not gain you much since that is probably an initialization or clear routine and called infrequently. the routine with the guts above is the one you want to parallelize and it simply needs a bit of "help" to the compiler to do the rest of the work. In the end you know, as the programmer, what is dynamic, and what is constant, what is changing via other threads, what is local, etc. Simply giving that a bit of thought and telling the compiler what to do with it will compile to N processors. But auto-parallelize is rare, and even still rarely as good as a bit of forethought.
_________________________
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:
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
Phil Martin... wrote:
Every time I hear someone say "Threaded programming is easy!" or "I know all about that threading stuff", I just cry a little inside.
Shucks, y'oughtn'ta cry over exaggeration and braggadocio, 's just the way some people communicate! Sure threads aren't easy, nothing worthwhile in this game is easy... the point is, it is worthwhile. I shudder though, every time i hear someone discouraged from using threads because "they're hard". So what? Usable UIs are hard, reliable command parsers are hard, robust network communication is hard, reliable serialization is hard, programming is hard. But oh, so useful. :)
----
Yes, but can you blame them for doing so if that's the only legal way they can hire programmers they want at the rate they can afford?
-- Nish on sketchy hiring practices
-
Phil Martin... wrote:
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 don't understand that. I did several years of work in Java back in 2000/2001 and I remember multi-threading seemed very similar to working with Win32 synchronization kernel objects of the same time period.
I am referring to java.util.concurrent There are a number of common threads (ha! I'm so punny!) with java.util.concurrent and some of the .net framework, but I haven't found all the replacements yet. But this is getting dangerously close to non-lounge talk. Naughty us! - Phil
-
Phil Martin... wrote:
Every time I hear someone say "Threaded programming is easy!" or "I know all about that threading stuff", I just cry a little inside.
Shucks, y'oughtn'ta cry over exaggeration and braggadocio, 's just the way some people communicate! Sure threads aren't easy, nothing worthwhile in this game is easy... the point is, it is worthwhile. I shudder though, every time i hear someone discouraged from using threads because "they're hard". So what? Usable UIs are hard, reliable command parsers are hard, robust network communication is hard, reliable serialization is hard, programming is hard. But oh, so useful. :)
----
Yes, but can you blame them for doing so if that's the only legal way they can hire programmers they want at the rate they can afford?
-- Nish on sketchy hiring practices
Most people are probably looking for
vbMultiThreadedControland won't be happy until they can drag/drop it onto their application and be done. :laugh:-- 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
-
Phil Martin... wrote:
Every time I hear someone say "Threaded programming is easy!" or "I know all about that threading stuff", I just cry a little inside.
Shucks, y'oughtn'ta cry over exaggeration and braggadocio, 's just the way some people communicate! Sure threads aren't easy, nothing worthwhile in this game is easy... the point is, it is worthwhile. I shudder though, every time i hear someone discouraged from using threads because "they're hard". So what? Usable UIs are hard, reliable command parsers are hard, robust network communication is hard, reliable serialization is hard, programming is hard. But oh, so useful. :)
----
Yes, but can you blame them for doing so if that's the only legal way they can hire programmers they want at the rate they can afford?
-- Nish on sketchy hiring practices
I'm totally with you on that one. I encourage just about everyone I meet to use concurrency, and boy do I get some strange looks from the McDonalds staff. They'll thank me one day though :) It is very worth while, and I don't design any system now without a fundamental underpinning of concurrency. And I probably stuff it up more often than not, but hey, it's all good fun. And I never want to discourage people, I just want people to be aware it isn't the easiest thing in the world, and you should respect them threadsies. And you are right, writing most anything in a really robust way automatically makes it hard! I also have italics envy. - Phil
-
I'm totally with you on that one. I encourage just about everyone I meet to use concurrency, and boy do I get some strange looks from the McDonalds staff. They'll thank me one day though :) It is very worth while, and I don't design any system now without a fundamental underpinning of concurrency. And I probably stuff it up more often than not, but hey, it's all good fun. And I never want to discourage people, I just want people to be aware it isn't the easiest thing in the world, and you should respect them threadsies. And you are right, writing most anything in a really robust way automatically makes it hard! I also have italics envy. - Phil
-
Most people are probably looking for
vbMultiThreadedControland won't be happy until they can drag/drop it onto their application and be done. :laugh:-- 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
-
See: BackgroundWorker drag'n'drop tour[^]... :doh:
----
Yes, but can you blame them for doing so if that's the only legal way they can hire programmers they want at the rate they can afford?
-- Nish on sketchy hiring practices
well that's a start, but if you drag a
vbMultiThreadedControlonto your existing crufty more or less upgraded to VB6 app it will magically run 4x faster on a quad core with no code changes whatsoever required. Just leave work early, goto the local bar and buy a Bud.-- 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