[Lazarus] semaphores

[waldo kitty]

On 2/14/2012 05:48, Hans-Peter Diettrich wrote:
> Lukasz Sokol schrieb:
>
>> System-wide solutions for Linux is the *Unix-way*, is to create a lock-file;
>> If you create one on a tmpfs mounted directory, it will all happen in memory,
>> hence no hard-drive storage access will happen (unless moved to swap, but in
>> your case it won't ever happen) so all you need to do is check for lock file
>> existence.
>
> How to use such an file?
>
> Does it have to be created to indicate a lock, and deleted again when done?

yes, this is basic semaphore signaling...

> Or is obtaining exclusive (r/w) access to the file equivalent to obtaining the
> lock?

in some cases, this may need to be done... i actually have some /old/ (TP/BP6/7) 
code (around) here (somewhere) that allows for "synchronized semaphore" work in 
that when the file is created, it is created with a specific number of bytes... 
the first process to acquire the semaphore opens it with read/write/denynone and 
does a region lock on the first byte... this allows another process to also 
acquire the semaphore and wait to lock the first byte... during this wait 
period, it has locked the second byte... when it can lock the first byte, it 
does so and releases the second byte... same thing for a third process except 
that it uses the third byte while waiting for the first one... basically the 
syncing comes from an orderly access... a process must also determine which byte 
is the last locked so that it can take the next one and not step in front of 
another process by snatching up an earlier byte...

the above worked great for the problem it was designed to solve but that problem 
could also have been handled by a simple semaphore design... one of the problems 
that was run into was when more than one process attempted to create the 
semaphore file... there needed to be a random delay inserted for the next 
attempt so that two or more processes didn't sit in a spin loop beating on each 
other trying to get the file...

> The latter looks the right way to me, because then the lock will be removed by
> the system on termination of the owning process, be regular or aborted.

this can be done but i have seen problems where files and regions were left 
locked when the app crashed... in those cases, the only fix was a reboot...