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 操作。