我想知道如果我可以使用一個信號量和互斥與Linux操作系統編程在C++與API semaphore.h。Semaphore.h沒有RTOS
我還沒有在代碼開發/寫入階段，但目標是在接收器上讀出一個接收器，它以115,200的波特率發出異步二進制數據。然後這些數據必須儘可能快地傳送到調制解調器中。
我在考慮使用RTOS，但我對bootloaders以及如何在芯片或嵌入式環境中獲得Linux或任何其他操作系統沒有任何瞭解。
是否可以將這些讀寫功能寫入由信號和管道互連的獨立線程中，並添加信號量？
當我必須以另一種格式格式化接收到的數據，僅解析所需的字符串，或者必須以數學方式修改它們時，可能需要信號量。發送出去之前。
使用非RTOS時可以獲得信號量的好處嗎？我只看到這些與RTOS合作應用。
POSIX semaphores與嵌入式應用程序中的RTOS信號量相比，在多線程Linux應用程序中與同步無關。
想想波特率意味着什麼115200 - 這是每秒11520個字符（假設8N1）或每個字符大約86.8個usec。現在Linux操作系統對於實時來說是變幻莫測的事情，但假設我們擁有1000hz的內核，這個時間約爲11.5倍，那麼我們肯定不會遇到大約1毫秒的粒度問題 - 只要您設置了調度程序即可。此外 - 從某種意義上說，這是最糟糕的等待時間 - 假設您可以保持輸出緩衝區已滿，批量寫入的字符將具有近乎完美的字符到字符延遲。
現在回答這個問題：你的應用程序可容忍什麼？根據答案，您必須考慮不同的事情 - 從用於Linux的實時補丁 - 到混合Xenomai/RTAI，再到像RTEMS這樣的完整RTOS。根據我對當前情況的理解，我認爲使用1000hz內核可能就足夠了。
可以在不同線程中同時寫入和讀取linux串行文件描述符，而不會出現問題。您可以將這些任務分離到不同的線程，或者使用非阻塞IO來交換無意義的延遲，只要您的處理很輕鬆 - 這可以避免上下文切換，這很好，因爲這些操作很慢。換句話說，如果使用線程或非阻塞模式，則不需要引入信號量。
最後 - 信號量在幾乎所有的操作系統的
將您的第一段作爲評論發佈 - 它不屬於答案。 – Clifford
在115200上流式傳輸數據的問題通常並不像您所建議的那樣負載很重;系統時鐘的粒度是無關緊要的，具有DMA或硬件FIFO緩衝器的串行UART將呈現遠低於CPU的負載，並且在應用程序處的顯示速率顯着降低。 – Clifford
@Clifford一個完整的緩衝區可能會給他的應用帶來無法忍受的延遲，並且UART緩衝區遍佈整個地方 - 從8個字符到64個字符;我也看到人們在串口設備上使用100hz內核時遇到問題，所以我認爲對他來說這不是一個好主意;你介意找到這個相關的：http://stackoverflow.com/questions/13126138/low-latency-serial-communication-on-linux –
目前尚不清楚你如何實施需要的信號，管道*和*信號燈;甚至爲什麼需要多線程才能提供足夠的緩衝，但如果您希望稍後將POSIX代碼移植到RTOS，則最好使用兩者中都存在的機制。 – Clifford