Thanks for responding Gé
There are the usual options of buffered and unbuffered file i/o in AmigaOS. A given file can be opened either in a shared mode, or an exclusive mode by a process, but it can also be locked first and then opened. It cannot be locked individually for a given pthread running in that process.
__For coarse grain locking there is Lock( filename, mode )__
Lock( ) allows you to lock a given file by name, and you get a lock descriptor. That lock descriptor can either be SHARED_LOCK ( ACCESS_READ ) or EXCLUSIVE_LOCK ( ACCESS_WRITE ), indicating more of the intention of the descriptor rather than causing any limitation on the outcome of a Read or Write operation on any resulting file descriptor. In any case the lock descriptor has to be held while its in use.
You can then access the file descriptor from that lock descriptor safe in the knowledge that it is yours.
The problem being that it locks the whole file, rather than individual records/ranges inside it. This is how I currently implement it to prevent two different processes both running on the same database from overwriting each other.
It works to a fashion, but its not sophisticated like I think it should be - and reading your reply, it could be.
__For fine grain lock there is LockRecord( ... ) and LockRecords( ... )__
LockRecord( ... ) allows you to lock a given range to yourself ( which I didn't actually realise I had as an option to be honest until I went back to the developer documentation for the OS just now ) in either EXCLUSIVE or SHARED mode.
LockRecords( ... ) allows you to lock multiple ranges to yourself at once ( kind of like a lockset ).
Both of those have optional timeouts, and IMMED suboptions to either wait for a lock or return straight away if its already locked.
Now Im not totally sure whether or not the lock record option treats individual threads as different potential lock holders, thats something Ill try in a minute ( and it isn't clear from the documentation either ). But it certainly locks it system wide.
So following your reply, it indicates that I should follow the Win32 implementation pattern? Then if I can confirm if threads are treated as individual lockholders or not I can use the AmigaOS pthread.library to multi-thread it. If not, it stays single threaded but at least potentially atomic system wide - which should be enough to make it a decent enough port.
Dave.
