better programming languages to support multiple Threads
Well, dual core processors are now going to be the standard for low end pcs thanks to the new price wars from Intel and AMD. And it's a shame that only one core will really be used most of the time since 99% of the programs out there are still single threaded. I think the reason for this is quite obvious, we just don't have a good programming language to support easy development of Threads.
With the state of current languages it is easy enough to create a Thread, and run it. But, we really need something even easier if we want more Threaded programs. I think there is a good opportunity for Java or C# to introduce new syntax for each language and it's JIT compiler to automattically make the program multi-threaded if it detects a core not being utilized.
lets say you had 3 methods, and all 3 methods could be executed at the same time, but all 3 needed to be done before the fourth method executed. - with new language syntax this could be achieved like this:
public void someMethodToRunTasks()
{
executeTask1() can run asynchrously
executeTask2() can run asynchrously
executeTask3() can run asynchrously
executeTask4() depends on executeTask1, executeTask2, executeTask3
}
then the respective JIT compiler could then take those dependencies and automattically create the best possible threaded program without the programmer doing anything except specifying the dependencies. Of course i don't think it's this simple (there would still be additional rules and behavior to be defined) but I think this is definitely doable, and would encourage development of multithreaded apps.
Have you checked http://en.wikipedia.org/wiki/Concurrent_programming and http://en.wikipedia.org/wiki/Software_transactional_memory?
A lot of your ideas are already realized in software, just not in plain C# or Java.
OpenMP makes it easy to add multithreading in C/C++/Fortran for trivially parallelizeable stuff like your example.
It would look somewhat like that (not tested, but I think it's right that way):
[Edited by - Trap on July 22, 2006 11:09:27 AM]
A lot of your ideas are already realized in software, just not in plain C# or Java.
OpenMP makes it easy to add multithreading in C/C++/Fortran for trivially parallelizeable stuff like your example.
It would look somewhat like that (not tested, but I think it's right that way):
void someMethodToRunTasks(){#pragma OMP parallel sections{#pramga OMP section executeTask1();#pragma OMP section executeTask2();#pragma OMP section executeTask3();}executeTask4();}
[Edited by - Trap on July 22, 2006 11:09:27 AM]
I believe Mutexes and Semaphores are busted in the .NET Framework 2.0 (Or at least lacking a full implementation). Thus, I don't recommend C#.
There's a lot of research going on in this area. Take a look at this presentation by Herb Sutter for some discussion about how to extend languages like C# and C++ to support higher level abstractions for concurrency.
There are 3 basic forms of concurrency seen in languages.
- Declarative concurrency. The simplest form, and the easiest to work with. You spawn off a purely functional function, let it do its work in parallel, and when you need the value it returns and try to use it, the system waits for the thread to terminate and yield its result.
- Message passing concurrency. Threads communicate via messages. Not quite as simple and as easy to reason about as option 1, but very powerful and relatively straightforward.
- Shared state concurrency. This is the model languages like C++ and C# are mostly stuck with. The combination of mutable variables with concurrency is very hard to reason about for a range of reasons. No need to be the default. When it is used, software transactional memory is a good technique for getting around having to use low level locks.
Quote:Original post by Thevenin
I believe Mutexes and Semaphores are busted in the .NET Framework 2.0 (Or at least lacking a full implementation). Thus, I don't recommend C#.
Could you be a bit more specific? What exactly is busted, and how is it busted? Are we talking about bugs or just missing features? If there's a problem with concurrency in .NET, I'd rather know it *before* I run into a situation where I have to debug it... [grin]
Quote:Original post by SpoonbenderI, too, would like to know what the hell you're talking about. Sounds like one of those "somebody somewhere mentioned it at some point, therefore it's fact" type things.Quote:Original post by Thevenin
I believe Mutexes and Semaphores are busted in the .NET Framework 2.0 (Or at least lacking a full implementation). Thus, I don't recommend C#.
Could you be a bit more specific? What exactly is busted, and how is it busted? Are we talking about bugs or just missing features? If there's a problem with concurrency in .NET, I'd rather know it *before* I run into a situation where I have to debug it... [grin]
Oh, and I think everybody should read the wikipedia article on Software Transactional Memory.
the only thing close to Thevenin's post that i'm aware of is the extremely suboptimal performance of readerwriterlock in the .net framework 2.0 .. nothing known to me otherwise concerning thread synchronization and the .net framework.
i suppose c#-wise it would be of great interest to grab the concurrency coordination runtime, CCR. currently it is only available via the robotics framework by microsoft into which the CCR has been integrated as its functionality is key to the robotics framework.
cheers,
simon
i suppose c#-wise it would be of great interest to grab the concurrency coordination runtime, CCR. currently it is only available via the robotics framework by microsoft into which the CCR has been integrated as its functionality is key to the robotics framework.
cheers,
simon
Quote:# Declarative concurrency. The simplest form, and the easiest to work with. You spawn off a purely functional function, let it do its work in parallel, and when you need the value it returns and try to use it, the system waits for the thread to terminate and yield its result.
# Message passing concurrency. Threads communicate via messages. Not quite as simple and as easy to reason about as option 1, but very powerful and relatively straightforward.
# Shared state concurrency. This is the model languages like C++ and C# are mostly stuck with. The combination of mutable variables with concurrency is very hard to reason about for a range of reasons. No need to be the default. When it is used, software transactional memory is a good technique for getting around having to use low level locks.
It is actually fairly simple to implement #1 using #3. In C++, I would create a proxy class. Upon creation the proxy would spawn another process to calculate the value. The other process would lock the proxy, calculate it, and unlock it. The original process would block on the lock when it tried to access the proxy. You do need a tad more book keeping to avoid a race condition. It would look something like this, in psuedo C++.
class proxy{ T value; Event is_ready; //Event is some concurency primitive that once triggered, //remains always triggered. IIRC, the 'events' in the //windows API don't have this behavior //You might even be able to use a bool (reads are atomic operations) //but then you would need a busy loop. :(public: proxy() { spawn_process(calculate_value,this); } T get_value() { wait for is_ready; return value; }};void calculate_value(proxy* p){ p->value = the_calculated_value; trigger p->is_ready;}int main(){ proxy p; p.get_value();}
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement