Add support for writing thread-aware device models #269
Conversation
| @@ -578,6 +594,172 @@ template device { | |||
| method destroy() default { } | |||
| } | |||
|
|
|||
| /** | |||
| ## Device templates | |||
There was a problem hiding this comment.
@AleksandrDanilovIntel Here's the documentation
|
@jakob-engblom-i Do you have an idea how to test the tread awareness of DML devices? |
Me and Erik have brainstormed some ideas, by abusing thread sleep to ensure the tests being deterministic enough. But really, it shouldn't be any different from tests on mutex implementations (save for the object/target/cell distinctions) so I can always just dig for ideas online. |
| into the device. This includes interface and attribute implementations, | ||
| callbacks of event objects and `after` statements, exported methods, | ||
| and method references converted to function pointers (except if the | ||
| method is `independent`.) |
There was a problem hiding this comment.
TODO: more hyperlinks
lib/1.4/dml-builtins.dml
Outdated
| @@ -1386,6 +1575,10 @@ The `init_as_subobj` inherits the [`init`](#init) and | |||
| template init_as_subobj is (connect, init) { | |||
| param classname : const char *; | |||
| param configuration default "none"; | |||
| #if (dev.thread_aware) { | |||
There was a problem hiding this comment.
TODO: document init_as_subobj as incompatible with thread-aware device models.
There was a problem hiding this comment.
This is because there is no way to prevent the created subobject from being placed in the same, independent thread domain as the device object; which is wrong if the subobject device class is not thread aware. (Well, ok, there is technically one way but it is horribly hacky and I'd consider non-viable.) The Framework team knows about this issue.
Gonna keep the documentation for now
lwaern-intel
force-pushed
the
lw/thread-aware
branch
from
7ce8717 to
3619403
Compare
|
Verification #13220390: fail |
Depends on #268
Tests are currently only a skeleton, cribbed from
1.4/misc/notify_state. As such, this is only a draft PR, and the implementation has not been tested for correctness. I've checked generated C and verified lock acquisition and releases are generated as desired, and compiles, but that is only one aspect of the whole implementation.@AleksandrDanilovIntel can't add you as reviewer for whatever reason, so pinging you instead.