Idea for Threads

[Daniel Keep]

Thomas Kuehne wrote:
> Craig Black schrieb am 2007-05-11:
>>> Correct me if I'm wrong, but the synchronize statement can be used to make a 
>>> function, block of code, or variable atomic.  That is, only one thread at a 
>>> time can access it. However, one very important objective of multithreading 
>>> is to make programs faster by using todays multi-core processors.  Using 
>>> synchronize too much would make things run slower, because it could cause a 
>>> lot of thread contention.
>>>
>>> I was thinking about this when I got an idea.  It would require another 
>>> keyword that could be used to mark a function or block of code.  Perhaps 
>>> "threaded" or "threadsafe".  This keyword would not force the code to be 
>>> atomic.  Instead, it would cause the compiler to issue errors when the code 
>>> does something that is not thread safe, like writing to nonsynchronized 
>>> data.
>>>
>>> I don't have a lot of experienct with threads so I don't know all the 
>>> implications here.  I'm not sure if the compiler has enough knowledge to 
>>> prohibit everything that could be the source of threading problems.  But 
>>> even if it could enforce the most common bugs then that would be a very good 
>>> thing.
> 
> This is an interesting idea, however the limitations for "threadsafe"
> code would be:
> 
> * no reference type arguments to the "threadsafe" function
> * no synchronized statements
> * no use of function pointers / delegates
> * no non-final class function calls
> * void pointers would require quite advanced compiler support
> * due to the current GC implementation:
>     no non-scope allocations, no .length changes
> * as a consequence of the GC issue:
>     no reference type return statement from the "threadsafe" function
> * the "threadsafe" function has to be
>     1) at module level or
>     2) a "static" struct function or
>     3) a "final static" class function
> 
> Most likely some restrictions are missing but this should give you an
> idea.
> 
> Some of those restrictions only apply to the top level "threadsafe" function.
> Depending on the sophistication of the compiler some limitation for
> functions called by the top level one might be lifted.
> 
> Thomas

Personally, I think the future of threading is not in making it easier
for programmers to write threaded code, but to make compilers smart
enough to automatically thread code.

I mean, from what I've seen, humans have displayed a real nack for not
being able to write multi-threaded code in any sane way.  I just don't
think we're wired up the right way.

That's why I've suggested things in the past like the concept of a
"pure" function--one which has no side effects.  If a function has no
side-effects, then the compiler can thread it automatically.  List
comprehensions and other functional features would help here, too,
allowing for loop parallelism.

I tell you what; the person who comes up with a general-purpose C-style
language that makes multithreading brain-dead simple will be one
seriously rich bugger.

Just my AU$0.02.

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/