Param thread safety

[twieman]

Parameter access should be thread safe. For example, we need to consider how tools interact with parameters (is it only when the simulation is not running?).

Ballpark effort estimate: 1/2 week.

[pah]

Can you give some more background on this one? What exact guarantee would (have to ) be provided to achieve "thread-safe parameter access"?

In general, we don't talk about multi-threading in SystemC standards as of today. If a tool would want to access the model while the simulation is running, it already has to somehow orchestrate these accesses in case multiple host threads are involved. This is not limited to parameter accesses.

Thanks,
Philipp

[markfoodyburton]

Hi, sorry, don't see this thread before :-)
The issue is that for parameter access, we can expect that the thing doing the access will be in a separate thread. This is the CCI interface, the expectation is we are going out of the model to a tool. It's not (so much) an internal SystemC question. To insist that the tool switches thread to access a parameter is 'painful' (needlessly). providing a way to ensure that they can be thread safe would be much less painful?

(anyway - I think we should talk about multi-threading, and in that light, building in the protection now - in this corner of the world - is only going to help us in the future :-) )

[pah]

I agree in principle on the goal to have a "thread-safe access guarantee" for parameters, as they are inherently accessed from a tool, which might be running in a separate host process.

I'm just wondering how to spell out the rules to achieve that?

• What restrictions do we impose on (user-defined) data types stored in a parameter that might not be atomically accessible?
• What are the requirements for custom parameter implementations, i.e. who enforces the safety?
• How to avoid deadlocks, e.g. due to callbacks?
• If any of the above needs to build on (standardized) synchronization primitives, don't we need to introduce "our own" API on top of host primitives?

To me, this somewhat sounds like a can of worms, especially when it comes to a portable PoC implementation. Can't we just let the tool providers worry about this for now? Or am I misreading the intent of this issue?

Thanks,
Philipp

[markfoodyburton]

We benchmarked adding a spin lock - seems we have an overhead of 8%.
My personal feeling is we should simply add the splin lock. It will mean that accesses from a tool (typically in a different thread) are not ever going to cause problems.

Given we have a lock in the param, I think some of your questions become easy. Given SystemC is single threaded, I dont think we need worry about deadlocks (if you are coding up parallel things, then you should be careful, but we can guarantee atomic access to the param).

We'll propose a patch, and see what the code looks like, and hoe portable we can make it.