May 13, 2007 Re: Idea for Threads | ||||
---|---|---|---|---|
| ||||
Posted in reply to Thomas Kuehne | > 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Craig Black Attachments: | 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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Craig Black | 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
|
Copyright © 1999-2021 by the D Language Foundation