Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thread Safe Status: Send Sync? #362

Open
edg-l opened this issue Oct 20, 2023 · 2 comments
Open

Thread Safe Status: Send Sync? #362

edg-l opened this issue Oct 20, 2023 · 2 comments
Labels
question Further information is requested

Comments

@edg-l
Copy link
Member

edg-l commented Oct 20, 2023

Whats the current status and plan on this?

According to the docs its looks complicated, apparently the MLIR context is thread safe but some stuff isnt https://mlir.llvm.org/getting_started/Faq/#registered-loaded-dependent-whats-up-with-dialects-management

@raviqqe
Copy link
Member

raviqqe commented Oct 22, 2023

I haven't really thought about it yet. But Melior is just a thin layer on top of the MLIR C API. So I think at least it's easy to make basic objects Send and Sync (we can just mark them with the traits unsafely) if they are at the C++ level.

For the context and dialect loading, when we mark the context, module, and other related types Sync and invoke the same passes at the same time, I believe that would not be thread-safe according to the documentation. So if basic objects like Operation, Type, etc. should be marked Sync, we might have no choice but to introduce dynamic checks for that and mark a context object Sync as well.

Also, I think at least everything is Send because parallel passes exist.

@raviqqe raviqqe added the question Further information is requested label Nov 23, 2023
@raviqqe
Copy link
Member

raviqqe commented Feb 24, 2024

Just for notes, currently, regions and blocks can't be Sync because of #347.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants