Thread Attributes

Jonathan Marler via Digitalmars-d digitalmars-d at puremagic.com
Thu Jul 10 11:12:02 PDT 2014


I had an idea this morning and wanted to post it to see what 
people think.

I know we have alot of attributes already but I'm wondering if 
people think adding a thread attribute could be useful.  
Something that says a variable or function or class/struct can 
only be accessed by code that has been tagged with the same 
thread name.  Something like this.

// This variable is allocated as a true shared global
// with a fixed location in memory since it can only
// be accessed by one thread.
@thread:main
int mainThreadGlobal;

@thread:main
int main(string[] args)
{
   // Start the worker thread at some point
}

@thread:worker
void workerLoop()
{
   // do some work , cannot access mainThreadGlobal
}

With this information the compiler could help verify thread 
safety at compile time.
This idea is far from refined as I just thought of it this 
morning, but I had a couple thoughts.
One problem I foresaw was how to handle passing callback 
functions into other libraries.
If the callback function is tagged with a thread name, then maybe 
you have to call that function on the same
thread that the callback is tagged with?
In example:

FindLibrary:
     // No thread attribute because it is a library function
     void find(string haystack, string needle, void function(int 
offset))
     {
       // logic...
     }
	
MyProgram:

	@thread:worker
	uint[] offsets;
	
	@thread:worker
	void foundOffset(int offset)
	{
	  offsets ~= offset;
	}
	
	@thread:worker
	void callFind(string data)
	{
	  find(data, "importantstring", &foundOffset);
	}	
	
	void main(string[] args)
	{
	    // start thread for callFind
	}


Now let's say that we didn't tag callFind with the @thread:worker 
attribute.
The compiler would need to know the source code of the find 
function but could throw an error when it sees that it calls the 
callback function passed into it tagged with a specific thread.
Or if you didn't know the source code of the find function, you 
could assume that it calls the callback function on it's own 
thread and just throw an error whenever you pass a callback 
function into another function that isn't tagged with the same 
thread you are currently executing on.

When something is not tagged with a thread (which would likely 
include any kind of library/api function, or any code in a single 
threaded application), then no checking is done.
But the @thread attribute would be guarantee that any function 
tagged with that attribute can only be called by a function 
tagged with the same attribute.


The other thought I had was handling synchronization.

Let's say you have a function that you don't mind being called by 
other threads but you still want it to be synchronized.
You could add a synchronized attribute that takes an object:

object mySyncObject;

@sync(mySyncObject)
void doSomething()
{
   // I don't need to synchronize on the mySyncObject here because 
the compiler will verify that
   // anyone who calls this function will have already 
synchronized on it.
   // Therefore I can assume I am already synchronized on the 
mySyncObject without actually doing it...yay! :)
}


So what do people think?  Like I said I just thought of this and 
haven't had time think about more corner cases so feel free to 
nit pick:)


More information about the Digitalmars-d mailing list