View mode: basic / threaded / horizontal-split · Log in · Help
May 13, 2007
Re: Idea for Threads
> This is an interesting idea, however the limitations for "threadsafe"
> code would be:
>
> * no reference type arguments to the "threadsafe" function

What if the references were read only?

> * no synchronized statements

Why not?

> * no use of function pointers / delegates

Because a threadsafe function shouldn't call a non threadsafe
function, right? Perhaps it would be possible to have threadsafe
delegates that could only be assigned with threadsafe functions.

> * no non-final class function calls

What do you mean by non-final?  Do you mean no virtual function calls?
Does this have something to do with non-threadsafe functions being
prohibited?

> * void pointers would require quite advanced compiler support

void pointers should probably be avoided.

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

Perhaps it could be a local member function if access to its
class data members was read only.

>
> Most likely some restrictions are missing but this should give you an
> idea.

It's a good start.

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

Not sure what you mean.

-Craig
May 13, 2007
Re: Idea for Threads
Craig Black schrieb am 2007-05-13:
>> This is an interesting idea, however the limitations for "threadsafe"
>> code would be:
>>
>> * no reference type arguments to the "threadsafe" function
>
> What if the references were read only?

References that point to immuteable data - or an immuteable view - are
basically just fancy value types and thus allowed. "read only" in
the sence of: can be changed by another thread but not this one is
generally illegal unless it can be ensured that no write thread is
executed during the "threadsafe" function's lifetime.

>> * no synchronized statements
>
> Why not?

synchronization via stack objects:
 causes idle dead locks once a second synchronize for the same object
 is encountered - there is only one stack/thread and no "try_synchronized".
 A single "synchronize" in the context of a "threadsafe" function has
 no effect.

synchronization via heap objects:
 not thread safe: all kinds of dead locks

>> * no use of function pointers / delegates
>
> Because a threadsafe function shouldn't call a non threadsafe
> function, right? Perhaps it would be possible to have threadsafe
> delegates that could only be assigned with threadsafe functions.

For function pointers this is possible but delegates would also require
"threadsafe" object that a guaranteed not to be used for synchronization
(see above).

>> * no non-final class function calls
>
> What do you mean by non-final?  Do you mean no virtual function calls?
> Does this have something to do with non-threadsafe functions being
> prohibited?

A really advanced compiler may allow seemingly virtual function calls.
Basically you have to know exactly what - if any - derived classes
could be encountered and that none of the potential objects is used in
a "synchronized" statement. Basically the compiler turned the virtual
call into a non-virtual one with a constrained object argument.

>> * 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
>
> Perhaps it could be a local member function if access to its
> class data members was read only.

Again the only-for-objects-without-synchronized-use limitation.

>> 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.
>
> Not sure what you mean.

# size_t getLen(Object o){
# 	return o.toString().length;
# }

# class C : Object{
# 	char[] toString(){
# 		return "123";
# 	}
# }
#
# size_t foo(){
#      scope Object o = new C();
#      return getLen(o);
# }

getLen is definetly not threadsafe. However foo - even though it
is calling getLen - is thread safe.

Thomas
May 14, 2007
Re: Idea for Threads (slightly OT)
Craig Black wrote

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

Tomorrow at 9:00 AM PDT there is a free "webinar" from Intel:

"Three Steps to Threading and Performance Part 2 - Expressing 
Parallelism: Case Studies with IntelĀ® Threading Building Blocks"

-manfred
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home