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

embassy_sync::Pipe with multiple writers #3301

Open
kbleeke opened this issue Sep 1, 2024 · 2 comments
Open

embassy_sync::Pipe with multiple writers #3301

kbleeke opened this issue Sep 1, 2024 · 2 comments

Comments

@kbleeke
Copy link
Contributor

kbleeke commented Sep 1, 2024

I'm using embassy_sync::Pipe to distribute variable sized messages within my application. The messages are framed and there is a single reader for each pipe. This works fine. (is there a better way?)

I have multiple writers that use write_all to push messages into the pipe. As long as the pipe is not full this should be fine, as the writers take the lock and write the message in a single write() call. However, I believe this has a race condition when the Pipe is full and multiple writers are racing to push more bytes into the pipe. It's not a data race but (at least in my case) simply undesired behavior.

I'm currently preventing this by acquiring an extra mutex for writing into the pipe. Does it ever make sense that concurrent write_all()s are racing? Would it make sense to acquire the pipe's internal mutex for the entire duration of write_all instead?

@kbleeke kbleeke changed the title Pipe with multiple writers embassy_sync::Pipe with multiple writers Sep 1, 2024
@Dirbaio
Copy link
Member

Dirbaio commented Sep 2, 2024

Pipe is a byte stream, it doesn't make sense to use it with multiple writers for packet-based data.

If we wanted to support this we'd have to add something like a "packet-based PIpe". You might want to check out bbqueue which is exactly that, it has async support I think.

@kbleeke
Copy link
Contributor Author

kbleeke commented Sep 3, 2024

I looked at bbqueue before but it seems to be purely SPSC

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

No branches or pull requests

2 participants