Thread Attributes

Jonathan Marler via Digitalmars-d digitalmars-d at puremagic.com
Fri Jul 11 10:07:27 PDT 2014


I'm not sure how AST macros would assist in thread safety the way 
that this feature would.  Maybe you could elaborate?

To explain a little more, when you put a @thread:name or 
@sync(object) attribute on something, the compiler will guarantee 
that no safe D code will ever use that code or data unless it is 
either on the given thread or can guarantee at compile time that 
it has synchronized on the given object.

You mentioned making the variable thread local.  So if I'm 
understanding, you're saying just make it a regular global 
variable.  However, the point is that if you tell the compiler 
that it can only be accessed by a single thread then it doesn't 
need to be thread local.  Real global variables are preferred 
over thread local for performance/memory reasons.  Their address 
is known at compile time and you don't need to allocate a new 
instance for every thread.  The only reason for thread local 
variables is to alleviate problems with multithreaded 
applications, but using an attribute like this would allow 
someone to have the benefit of a real global variable without 
exposing it to other threads fixing the synchronization issue.

D has its own way of handling multithreaded applications but I 
still have applications that use the old idioms to get lightning 
performance and minimize memory usage.  A feature like this could 
solve alot of problems the old idioms use.  There are many times 
that I write a function and I have to make a mental note (or a 
comment) that this function should only ever be called by a 
certain thread.  Or that this function should only be called by 
code that has locked on a certain object.  It would be wonderful 
if the compiler could guarantee that for me.


More information about the Digitalmars-d mailing list