Files as semaphores

Sometimes files are used as a substitution of semaphores.
Are they safe in a multiprocessing and multiprocessor system (unix)?
Are they safe in theory?
Can anybody give me some hints where I can find further information.

Tanks
Heiner

hfk <hfk@dr-k.de> wrote:
> Sometimes files are used as a substitution of semaphores.
> Are they safe in a multiprocessing and multiprocessor system (unix)?

poor man's slooow gadget. Better use Ada's protected types:
http://www.ihr.uni-stuttgart.de/fors...ources_on_ada/
With free and open source compilers you even get a convenient
distribution to CPUs of your parallel tasks.

Responding to Hfk...

> Sometimes files are used as a substitution of semaphores.
> Are they safe in a multiprocessing and multiprocessor system (unix)?
> Are they safe in theory?

The short answer is that they are as safe as the developer makes them.
B-) There is nothing inherent that would make files less safe than
semaphores. Imagine the semaphores stored in an RDB rather than memory.
The basic semantics and processing logic is unchanged.

However, they do have special problems that the developer must design
against. The obvious one is performance. Clearly files are a lot slower
and that may result in deadlock problems when accessed concurrently.
Another problem is synchronization. Any time data updates are outside
the scope of a single process there is a potential for synchronization
issues. (Presumably the reason you are even tempted to use files is
because you need interoperability between processes that come and go.)
Worse, those problems may be more difficult to recognize. Yet another
problem can be initialization/recovery (e.g., if an updating process
crashes the file state may not be properly reset for the next startup).

Bottom line: though they are not inherently less safe, more things can
go wrong and the developer may have to provide additional infrastructure
to ensure safety.


--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

On 5 Aug., 20:10, "H. S. Lahman" <h...@pathfindermda.com> wrote:
> Responding to Hfk...

> Another problem is synchronization. Any time data updates are outside
> the scope of a single process there is a potential for synchronization
> issues. (Presumably the reason you are even tempted to use files is
> because you need interoperability between processes that come and go.)
> Worse, those problems may be more difficult to recognize. Yet another
> problem can be initialization/recovery (e.g., if an updating process
> crashes the file state may not be properly reset for the next startup).

That is, you would not trust on file semaphores.

To be a bit more clear - and a answer to peter.herm.

Using files as semaphor is bad progamming practice.
Using semaphors is not state of the art, using Ada concepts is much
better.

My problem is:
I found Ada code using files as semaphor to comunicate to other
system tasks. These tasks are Ada programs - not Ada tasks.
All these concepts are very poor and critical of course.

But I am interisted in the fact:

Suppose the code is correct. Can I trust on the concept using files as
semaphore?

If I open a file for writing, is it NOT possible that any other system
task can open
a file with the same path/name at the same time and any of the taks
gets NO error or
exception?

Thank you
Heiner

Responding to Hfk...

>> Another problem is synchronization. Any time data updates are outside
>> the scope of a single process there is a potential for synchronization
>> issues. (Presumably the reason you are even tempted to use files is
>> because you need interoperability between processes that come and go.)
>> Worse, those problems may be more difficult to recognize. Yet another
>> problem can be initialization/recovery (e.g., if an updating process
>> crashes the file state may not be properly reset for the next startup).
>
> That is, you would not trust on file semaphores.
>
> To be a bit more clear - and a answer to peter.herm.
>
> Using files as semaphor is bad progamming practice.

Only when there are better alternatives -- and there usually are. Note
that if you need to preserve the state data when none of the relevant
processes are running, you really don't have any choice about using some
kind of data storage. So it can't be a bad practice in that situation
because it's the only practice. B-)

> Using semaphors is not state of the art, using Ada concepts is much
> better.

And if Ada is not an option? [I haven't used Ada in more than two
decades so I don't even recall the sort of facilities to which you
refer. We also may have different definitions for process, task, and
program, so let's not get hung up on Ada-specific terminology.]

Whether a specific language provides interoperability facilities is not
very relevant. If there are better facilities available, one should use
them. Using files for inter-process communication is, indeed, old
practice so I assumed that other alternatives had been eliminated.

[Note that the modern interoperability infrastructures like CORBA
provide facilities to support such synchronization. Using them would
eliminate the need for files -- unless the state data needs to be
preserved when *all* the relevant processes go away. That is, the
interoperability infrastructures are designed to coordinate active
processes, not inactive ones.]

>
> My problem is:
> I found Ada code using files as semaphor to comunicate to other
> system tasks. These tasks are Ada programs - not Ada tasks.
> All these concepts are very poor and critical of course.
>
> But I am interisted in the fact:
>
> Suppose the code is correct. Can I trust on the concept using files as
> semaphore?

Whether it is correct will depend on the context for *your* system. The
code to manage synchronization in such situations tends to be customized
because issues like security against hackers may or may not be relevant.
So the code may be correct for other, different contexts but not for
your context.

>
> If I open a file for writing, is it NOT possible that any other system
> task can open
> a file with the same path/name at the same time and any of the taks
> gets NO error or
> exception?

Whether that is possible depends upon the overall system context. That's
a matter for requirements analysis and systems engineering for *your*
system's environment.

If it is possible, then you would have to provide infrastructure to deal
with the synchronization issues, as I indicated. That infrastructure
might need to be quite complex (e.g., a dedicated process to manage the
file updates with registration/notification facilities for the clients
using those files).


--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

hfk wrote:

> Sometimes files are used as a substitution of semaphores.
> Are they safe in a multiprocessing and multiprocessor system (unix)?
> Are they safe in theory?
> Can anybody give me some hints where I can find further information.

Which Unix are you using ??

1. SunOS (Solaris) I believe provides the std concurrency schemes (mutex,
semaphore etc) at both intra (thread) and *inter* process levels.

2. If the schemes in 1 are standardised (POSIX etc) , there is a chance
of support on Linux (std, realtime) or a POSIX-compliant RTOS (QNX is a
good bet, VxWorks a possible) .


Regards,
Steven Perryman