View mode: basic / threaded / horizontal-split · Log in · Help
May 11, 2007
Idea for Threads
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.

Comments?

-Craig
May 12, 2007
Re: Idea for Threads
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
May 12, 2007
Re: Idea for Threads
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/
May 12, 2007
Re: Idea for Threads
[snip]
> 
> 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
> 

Very true.

-Joel
May 12, 2007
Re: Idea for Threads
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
May 12, 2007
Re: Idea for Threads
Daniel Keep, el 12 de mayo a las 17:58 me escribiste:
> That's why I've suggested things in the past like the concept of a
> "pure" function--one which has no side effects.

Like Haskel (and other functional languages). Maybe some experience could
be collected from it.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
.------------------------------------------------------------------------,
 \  GPG: 5F5A8D05 // F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05 /
  '--------------------------------------------------------------------'
Peperino nos enseña que debemos ofrendirnos con ofrendas de vino si
queremos obtener la recompensa de la parte del medio del vacío.
	-- Peperino Pómoro
May 12, 2007
Re: Idea for Threads [a bit OT]
Thomas Kuehne wrote:
> 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.

I don't want to say anything about threading, but I'd say the compiler/language
shouldn't be designed for C coders, but the C coders should look at the
compiler/language spec. In the case the coder still likes to stick to the C way
of doing, he should definitely stick to C.

best regards,
Nicolai
May 12, 2007
Re: Idea for Threads
Daniel Keep wrote

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

This is not possible for compilers in general because
- algorithms for single or quasi-single processors may loose 
performance drastically when the number of threads supportable by the 
hardware increases, i.e. more processors become available.
- in a system that dynamically assigns processors to a process the 
compiler has to know in advance the effects for every possible change 
of the assigned number of processors

-manfred
May 12, 2007
Re: Idea for Threads
Craig Black wrote

> However, one very important objective of multithreading 
> is to make programs faster by using todays multi-core processors.

There is at least one simple test, whether a language is prepared for 
parallel execution: the computation of the parallel or: por.

por( arg1, ..., argn)
- evaluates all of its arguments simultaneously
- returns true as soon as one of its arguments turns out to be true
- stops all evaluations of its arguments, that are still running, as 
soon as it returns.

-manfred
May 12, 2007
Re: Idea for Threads
Manfred Nowak wrote:
> There is at least one simple test, whether a language is prepared for 
> parallel execution: the computation of the parallel or: por.

I suppose it's dual pand should then be just as suited.
With pxor, alas, the short-circuiting might get a bit tricky... :)

regards, Frank
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home