Idea for Threads

[Thomas Kuehne]

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

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

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

iD8DBQFGRxgGLK5blCcjpWoRAkU2AKCnKoW/qQ+SmJIqhiC//rutu0M5JgCfaxLS
K4kLhwZeCY6KKio4Ce1mQA4=
=xxZx
-----END PGP SIGNATURE-----