Aros/開發者/文件/庫/AROSC
arosc 庫僅允許一次只有一個任務呼叫具有相同 libbase 的函式。據我所知，這不會違反任何標準。在以後的階段，將提供一個執行緒實現，它將對需要進行適當鎖定的 C 函式進行鎖定，當您實現自己的執行緒實現時，這也應該可以使用。
當前的 arosc 不是執行緒安全的，ABI V1 中的 C 庫也不是。最好的方法是在 AROS 上擁有類似於 clib2-ts 的前端。
YAM 沒有使用任何執行緒庫，而是使用它自己的執行緒實現。即使它使用 pthreads 之類的東西，C 執行時庫也負責保護其內部內容免受競爭條件的影響。沒有任何執行緒框架能夠從 C 庫中解除安裝此負載，因為這是內部內容。
對於 AROS 的 arosc.library，在對 __stdio_files 列表的所有隱式和顯式訪問進行簡單地 ObtainSemaphore()/ReleaseSemaphore() 配對將是一個良好的開端。但是，很可能還有許多其他位置需要強制單執行緒以避免競爭條件。
作為一種中間解決方案，已經可以提供一個靜態連結庫，它會在需要它的函數週圍進行適當的鎖定，例如 arosc-ts（類似於 clib2-ts）。
也許您應該聯絡 Olaf Barthel 並將其 clib2 移植到 AROS。我已經詢問過他，他對此類移植沒有異議。使用 clib2 的系統越多，發現的錯誤就越多。我認為作為靜態連結庫的 clib2 C 實現將補充依賴於某些 clib2 特性的程式的 AROS C 共享庫。
這可能有點天真，我們可能需要考慮為每個執行緒進行 AROS C *共享* 庫的 OpenLibrary()。這消除了鎖定問題，我們只需要使 AROS C 資料區域對每個執行緒都是私有的。
這可能需要一些標頭檔案和連結器支援，但它應該比完整的鎖定實現更容易實現，並且將是輕量級的程式碼更改。這不是使用者想要的。他們希望能夠讓一個執行緒使用另一個執行緒開啟的檔案進行 IO 操作。