May 13, 2007
> 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
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
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
1 2
Next ›   Last »