❔ i don't have enough (any) experience with semaphores to know if my wpf app requires them
i started a new role very recently and my first project is helping a client, an electrical engineer, create a desktop application to manage a robotic platform performing qa for silicon manufacturing.
understandably, one of the requirements was that the ui not lock up during an interaction; the previous desktop application they had made some years ago was a winforms app that did similar work, and in typical cobbled-together winforms fashion, everything was done on the ui thread. i've demonstrated with a reasonable sample wpf app that this won't be the case.
however, the word "semaphore" was introduced by my project lead when we had our project start call with the client, and a lot of our conversation about creating a background thread for any singular task is now intertwined with the thought that it requires a semaphore. from what i've learned about semaphores and their usage, they control the number of threads that can be used at any given time by a module in an application, which helps limit the number of times some kind of external resource or endpoint is being accessed by the module (i.e., respecting rates for web apis). i found these when searching for c#-based examples of semaphores:
https://kendaleiv.com/limiting-concurrent-operations-with-semaphoreslim-using-csharp/
https://www.youtube.com/watch?v=GKjM4AX8NME
from my current understanding of the project requirements, the wpf app would be a wrapper around a library for interacting with the robotic platform. i don't have enough experience with semaphores to know if this project will have so many simultaneous interactions that it'd be necessary to have a semaphore. my current assumption is that having a semaphore might act as a queue of sorts if a user decided to press several buttons consecutively, but it'd probably be more reasonable if there was a queue keeping track of the actions a user was triggering.
is my understanding of semaphores correct? do i have an immediate need for them based on the requirements?
understandably, one of the requirements was that the ui not lock up during an interaction; the previous desktop application they had made some years ago was a winforms app that did similar work, and in typical cobbled-together winforms fashion, everything was done on the ui thread. i've demonstrated with a reasonable sample wpf app that this won't be the case.
however, the word "semaphore" was introduced by my project lead when we had our project start call with the client, and a lot of our conversation about creating a background thread for any singular task is now intertwined with the thought that it requires a semaphore. from what i've learned about semaphores and their usage, they control the number of threads that can be used at any given time by a module in an application, which helps limit the number of times some kind of external resource or endpoint is being accessed by the module (i.e., respecting rates for web apis). i found these when searching for c#-based examples of semaphores:
https://kendaleiv.com/limiting-concurrent-operations-with-semaphoreslim-using-csharp/
https://www.youtube.com/watch?v=GKjM4AX8NME
from my current understanding of the project requirements, the wpf app would be a wrapper around a library for interacting with the robotic platform. i don't have enough experience with semaphores to know if this project will have so many simultaneous interactions that it'd be necessary to have a semaphore. my current assumption is that having a semaphore might act as a queue of sorts if a user decided to press several buttons consecutively, but it'd probably be more reasonable if there was a queue keeping track of the actions a user was triggering.
is my understanding of semaphores correct? do i have an immediate need for them based on the requirements?
