Idea for Threads

[Thomas Kuehne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Keep schrieb am 2007-05-12:
>
>
> 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.

[...]

> 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 think a combination of both approaches will yield the best results.
I especially like GCC's --Wunsafe-loop-optimization and
 --Wdisabled-optimization. Combining those with cross module
optimization, automatic threading and a "tell me if you can't auto-thread
this function" attribute/pragma should result in a really helpful compiler.

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

# int foo(int* i){
#    *i += 1;
#    retrun *i;
# }

foo clearly isn't a "pure" function, thus can't be called by another
"pure" function.

# int bar(int i){
#    int j = i * i;
#    return foo(&j);
# }

bar calls an "unpure" function thus would normally not be considered "pure".
However bar is "pure" - there are no side effects <g>

If your definition of "pure" includes bar it might be of use for the
majority of C style coders. If it doesn't consider bar a "pure" function
a lot of C style coders will have to re-train to use the features of
your smart compiler.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFGRaFqLK5blCcjpWoRAuzEAKCIxsIcBSH/B5EN+60uVF5Dd77X5QCeK4CK
UP5A1PTOqct48MQ8YieRzDk=
=8s6H
-----END PGP SIGNATURE-----