On 14/07/14 23:26, Jonathan Marler wrote:
Ah I see now. It looks like AST macros are going to open up alot of new paradigms, I'm excited to see how they progress and what they can do. It doesn't get us all the way there in this example but its a very good alternative without having to add anything to the compiler. Your macro would help the developer ensure that particular variables and functions are only touched by the appropriate code. If the feature only did this I would use a different name such as "restrict" or something. However, in order for the compiler to perform thread-optimizations based on this information it would have to be apart of the language.
Yeah, probably. I think the problem is that threads are not so tightly couple with the language. They're mostly implemented in the runtime.
Perhaps it's possible to if you could attach a thread name, globally to indicate the current thread. When the @thread macro is used on a function it would check if a new thread is created. If it is, it would attach a name to the current thread variable, somewhere in the AST.
When the @thread macro is used on a variable, it would check context and get all callers (if possible). It would get the thread name of the caller and see if it matches the current global thread name. Otherwise issue an error.
I have no idea if this is possible, if it is it sounds quite complicated. It would be easy to verify at runtime at least.
It also doesn't handle the synchronized case. For that you would need a knowledge of the execution paths of your functions to determine what parts are locked and what parts are not (Unless of course AST macros could support that, I would be very pleasently surprised if they did).
If you could do something similar as above and get the caller of a function with the @sync macro/attribute. The AST of a synched object (mySyncObject) would have some way to indicate if it's currently synced or not.
This AST macro is very intriguing though. Its like you're writing code that can analyze your code as you develop it. This is a really cool idea. As I've had more time to think on this here's one of the potential consequence I've thought of. *********** Deprecating usage of the __gshared hack *********** Here's some cases that a developer may think __gshared usage is justified. 1. In a single threaded application 2. When the developer knows that its only possible for one thread to access that global at a time or, 3. When the developer is using some type of locking scheme to access the globals is the correct design. In a single threaded application then you could add the thread attribute with the same name to every single function and variable, but this would be very unnecessary. Instead the developer could use a pragme to tell the compiler to make sure it is single threaded, but since adding this feature would require the compiler to know when threads are started anyway, the compiler could determine that an application was single threaded on its own. The pragma would just be a sanity check so that the developer would be notified when their code has changed to break the initial design.
That would be a lot easier to do in the compiler. Or just remove it from the runtime.
-- /Jacob Carlborg
