Remove serial signalling protocol from producers to consumers#305
Merged
Conversation
Courtney3141
force-pushed
the
serial_producer_signal_unconditional
branch
from
January 13, 2025 04:15
1949d59 to
872542c
Compare
Courtney3141
force-pushed
the
serial_producer_signal_unconditional
branch
from
January 13, 2025 04:23
872542c to
2dec068
Compare
JE-Archer
changed the base branch from
main
to
simplify_serial_queue_interface
January 14, 2025 07:13
JE-Archer
changed the base branch from
simplify_serial_queue_interface
to
split_serial_rx_tx_clients
January 14, 2025 07:13
Courtney3141
force-pushed
the
serial_producer_signal_unconditional
branch
from
January 15, 2025 07:13
2dec068 to
079bbdc
Compare
Courtney3141
changed the base branch from
split_serial_rx_tx_clients
to
simplify_serial_queue_interface
January 15, 2025 07:15
Courtney3141
force-pushed
the
simplify_serial_queue_interface
branch
from
January 15, 2025 07:16
524ca66 to
41b35a2
Compare
Courtney3141
force-pushed
the
serial_producer_signal_unconditional
branch
2 times, most recently
from
January 15, 2025 07:26
23a7090 to
0df8f55
Compare
Courtney3141
force-pushed
the
simplify_serial_queue_interface
branch
from
January 17, 2025 06:58
41b35a2 to
d8bed51
Compare
Courtney3141
force-pushed
the
serial_producer_signal_unconditional
branch
from
January 17, 2025 07:02
0df8f55 to
ea468fb
Compare
Courtney3141
force-pushed
the
simplify_serial_queue_interface
branch
from
January 25, 2025 02:07
d52a7d8 to
bdb9b0b
Compare
alwin-joshy
previously approved these changes
Jan 28, 2025
Ivan-Velickovic
dismissed
alwin-joshy’s stale review
January 30, 2025 06:03
The base branch was changed.
Signed-off-by: Courtney Darville <courtneydarville94@outlook.com>
Ivan-Velickovic
force-pushed
the
serial_producer_signal_unconditional
branch
from
January 30, 2025 06:04
ea468fb to
42d5e9a
Compare
Ivan-Velickovic
enabled auto-merge (rebase)
January 30, 2025 06:06
Ivan-Velickovic
approved these changes
Jan 30, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currently, both the consumer and producer of a serial queue only signal each other if their corresponding flags are set - there are two flags for each queue. This is in contrast to the networking subsystem, where the consumer never signals the producer, and the producer only signals the consumer depending on the value of the flag.
Since the serial subsystem is using a signalling protocol for both directions of communication, it makes the code quite complicated to read and understand for those who are unfamiliar with the protocol. Since the serial subsystem is not performance critical, and the risk of over signalling even with unconditional signalling is very low, I have decided to remove one direction of the signalling protocol so that producers of serial queues signal consumers unconditionally after a batch of work has been enqueued.
The consumer side of the protocol remains unchanged, as typically producers do not require signals from consumers - it is only required when a queue has become full and there is still more data to be enqueued. Since under normal conditions this does not occur frequently, it makes sense to keep the protocol for this direction of communication.
Merge after #301.