|
At work I've VC6... probably I'll use parallel extensions or .NET 4.0 in a new life.
(Or at home in the free time  )
Dr.Luiji
Trust and you'll be trusted.
Try iPhone UI [ ^] a new fresh face for your Windows Mobile, here on Code Project.
|
|
|
|
|
I'm still in the works of getting my head around all the api changes that microsoft introduced in C# 4.0, I will however check it out and will most likely use it in future applications.
|
|
|
|
|
|
So MS are not abandoning C++ after all. 
Kevin
|
|
|
|
|
So MS is reinventing OpenMP? I tell you, if they don't own it then they always seem to feel the need to reinvent it and get everyone to use their creation.
|
|
|
|
|
I don't know anything about those extensions, but as a rule of thumb I avoid multithread code if possible, because it's always a nightmare to debug.
|
|
|
|
|
|
It's only a nightmare to debug if the design was already a nightmare.
Silver member by constant and unflinching longevity.
|
|
|
|
|
That's where those extensions really come in - they make it easier
|
|
|
|
|
ed welch wrote: I avoid multithread code if possible, because it's always a nightmare to debug.
Yes, but these bugs are sooo easy to introduce
Seriously, you are right. "Classic" multithreaded programming with a bunch of threads sharing the memory space and using locks and events to synchronize them is very error prone and that's exactly why these new libraries and language extensions are being introduced.
|
|
|
|
|
From what I read on wikipedia, it's just a parellel task design pattern. You still need to put locks on shared data... so no, it doesn't magically solve the problems of multi-threading.
|
|
|
|
|
Then don't use them in places where you would have to lock data..
Locking is extremely slow, so any speedup you might get from using more threads, you would immediately lose.
Not always of course, but it's often the case.
It's better to split tasks that are actually independent.
|
|
|
|
|
Ha, ha. Well, if you don't share any data between threads then you don't need to lock anything and multithreading becomes a whole lot easier. Unfortunately, in real world cases threads do share data
|
|
|
|
|
ed welch wrote: Unfortunately, in real world cases threads do share data
Or at least exchange data
Take a look at this article on Erlang-style[^] concurrency.
Also, I am pretty sure there was a nice article by Marc Clifton on using messages instead of locks with some benchmarks, but this guy has so many articles that I can't find this one.
|
|
|
|
|
Nemanja Trifunovic wrote: Take a look at this article on Erlang-style[^] concurrency
And Microsoft have an Erlang clone in the works...
Axum[^]
Kevin
|
|
|
|
|
Intresting, but I can't figure out why they insist on C-like syntax when compatibility with C is not a goal.
|
|
|
|
|
I think it's just part of the common idea that new languages must use C-style syntax in order not to alienate C-syntax developers.
In this respect it will be interesting to see how F# fares once it's officially released as its syntax makes no concessions to C-syntax.
Scala, which is doing a similar job to F# on the Java side does make concessions to C-syntax, though is a bit Eiffel-like as well. Scala is a bit more accessible than F# actually but I don't think it's entirely down to familiarity of syntax. Probably when they get to advanced scenarios they are just as befuddling.
Kevin
|
|
|
|
|
Kevin McFarlane wrote: I think it's just part of the common idea that new languages must use C-style syntax in order not to alienate C-syntax developers.
I agree, but it is still ugly. I've been working mostly with C-like languages since the university days, and still don't like the syntax.
|
|
|
|
|
I agree with you, we should be moving to better syntax. The C-syntax was good given its historical context but we should be moving beyond it. However, from a business perspective, and given the conservatism of many developers, I can see why Java and C# stuck with it.
Kevin
|
|
|
|
|
If you have a highly contentious multithreaded process, then I would say that your using threading incorrectly, and you are probably better off using a serial process instead.
Parallelization is usually applied when you have independant data sets that can be processed without the need to lock and write shared data. When it comes to read-only shared data, then no locking, reader/writer locking or copying read-only shared data locally to each thread can reduce most performance bottlenecks. The Task Parallel library is intended to solve those cases where you have divisable data sets that can be worked in in an independant, safe manner.
|
|
|
|
|
I must say that I agree with the original poster... it's a nightmare to debug. And this is not a problem of structure, is a problem with the debugger itself.
When I developed for BeOS I liked the fact I can have one window per thread, so I could really see what was happening and affect it.
But, for the other comments about locking shared data and so on, I see a problem there, and the problem are created by the not-so good developers, that will develop in the same teams as the good ones.
I already corrected bugs in frameworks used all around the world, that were flawed because the lack of locking in right places. And, worst, the developers that did it really thought locks were not needed, as it was sometimes commented in the code.
I really like threading. I use threads a lot and, to be honest, I think a parallelforeach (or asyncforeach) will be better than extension methods to make thinks parallel, but I really see many bugs comming from developers that are not aware about things they must NOT do.
|
|
|
|
|
|
With the new debugging window for parralell processing it is a breeze.
Check out the following presentation (few slides lots of code):
http://channel9.msdn.com/pdc2008/TL26/
Vita est usquequaque virtus victus ut plenus. Ego non sum semper iustus tamen Ego sum nunquam nefas!
|
|
|
|
|
At work we are bound to our customers specifications.
And they have a very large network of old, single-core, computers, that won't replace, so we won't probably use .NET 4.0.
Migrating some applications to WPF and framework 3.5 was a big step/problem.
So I'll stick with 3.5 for a while
|
|
|
|
|
Very much true. I still have to ensure that sections of our product are able to run on 1.1 too.
It is the client that signs the pay check and we need to go by their business requirements rather than being lured and carried over by fantasies unleashed by technology vendors.
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
