Jump to content

Aros/Developer/Docs/Libraries/AROSC

From Wikibooks, open books for an open world
Navbar for the Aros wikibook
Aros User
Aros User Docs
Aros User FAQs
Aros User Applications
Aros User DOS Shell
Aros/User/AmigaLegacy
Aros Dev Docs
Aros Developer Docs
Porting Software from AmigaOS/SDL
For Zune Beginners
Zune .MUI Classes
For SDL Beginners
Aros Developer BuildSystem
Specific platforms
Aros x86 Complete System HCL
Aros x86 Audio/Video Support
Aros x86 Network Support
Aros Intel AMD x86 Installing
Aros Storage Support IDE SATA etc
Aros Poseidon USB Support
x86-64 Support
Motorola 68k Amiga Support
Linux and FreeBSD Support
Windows Mingw and MacOSX Support
Android Support
Arm Raspberry Pi Support
PPC Power Architecture
misc
Aros Public License

Introduction

[edit | edit source]

The arosc library only allows that one task at a time calls a function with the same libbase. AFAIK this does not break any standards. In a later stage a thread implementation will be provided that will to do proper locking around the C functions that need, this should also be usable when you implement your own thread implementation.

Current arosc is not thread-save and the C libs in ABI V1 neither. The best way to get is have a front-end similar to clib2-ts on AROS.

YAM is not using any threading library but its own thread implementation. And even if it would use stuff like pthreads it is the C runtime lib's task to protect its internal stuff from race conditions. No thread framework is able to take this load off the C lib, because this is internal stuff.

For AROS' arosc.library a simple ObtainSemaphore()/ReleaseSemaphore() pair around all implicit and explicit accesses to the __stdio_files list would be a good start. However, there will very probably be many more locations which require enforced single threading to avoid race conditions.

As an intermediate solution already a static link library can be provided that does the proper locking around the function that need it, e.g. arosc-ts (analog to clib2-ts).

Perhaps you should contact Olaf Barthel and port over his clib2 to AROS. I already asked him and he has no objections against such a port. The more systems use clib2 the more possible bugs will be found. I think clib2 C implementation as a static link library would complement the AROS C shared libraries for the programs that depend on certain clib2 peculiarities.

This may be a bit naive, we may need to consider an OpenLibrary() of the AROS C *shared* library for each thread. That eliminates the locking issue, we just need to make the AROS C data area private to each thread.

This may need some headers and linker support, but it should be much easier to implement than a full locking implementation, and would be a lightweight code change. That is not what users want. They want to be able to have one thread do IO with a file opened by another thread.

Examples

[edit | edit source]

References

[edit | edit source]