Sign in to follow this  
dtaylorjr

Unity better programming languages to support multiple Threads

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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):
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]

Share this post


Link to post
Share on other sites
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#.

Share this post


Link to post
Share on other sites
There are 3 basic forms of concurrency seen in languages.

  1. 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.

  2. 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.

  3. 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.

Oz and Alice feature all models. Erlang is built around message passing concurrency. The problem of handling concurrency has actually been adequately solved for some time, although no mainstream languages provide good support. Sutter's Concur project aims to bring support for message passing concurrency to C++, and Microsoft Research have been experimenting on adding features from join calculus to C#.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
Quote:
Original post by Spoonbender
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]
I, 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.

Oh, and I think everybody should read the wikipedia article on Software Transactional Memory.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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

Share this post


Link to post
Share on other sites
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();
}

Share this post


Link to post
Share on other sites
Quote:
Original post by Deyja

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




Yes they do, provided you call the CreateEvent() function with the bManualReset argument passed as TRUE.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this