Browse Prior Art Database

Process Synchronization using a file system

IP.com Disclosure Number: IPCOM000033201D
Original Publication Date: 2004-Dec-01
Included in the Prior Art Database: 2004-Dec-01
Document File: 4 page(s) / 54K

Publishing Venue

IBM

Abstract

Process synchronization between a server and client using a file system is disclosed.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 4

Process Synchronization using a file system

The problem solved by this invention is to establish a common code approach to allow for synchronization between a server process and a client process that can be used by many people in various instances.

     Originally, this was designed using a semaphore. However, problems arose with the blocking of the client as removing a semaphore was not signal handler safe. There are also issues with the initialization sequence for semaphores, particularly in the Linux* environment. Thus, the move to the file system because the unlinking of a file is signal handler safe and avoided initialization problems.

     By using the file system, this solution will not work in an environment where the client and server are within the same address space (i.e., sharing the file descriptor) as in a multi-threaded application. As long as the client and server do not share the file descriptor, the client may contain any number of threads or processes.

     The Process Synchronization can be used as a utility to synchronize when a server process is ready to interface with a client process. The server process could be a daemon and the client could be a process that wishes to send messages to the daemon. The Process Synchronization utility would allow for the client process to know when the server process is ready to accept messages. The Process Synchronization utility is signal handler safe and is able to handle extreme conditions of termination.

     Most clients cannot use a server before the server is ready for interfacing. When a client attempts to use a server before it is ready, failures and errors can occur. When the server and client are started, a race condition can occur between them. The client must wait for the server to run far enough such that the server is ready for interfacing with the client.

     The Process Synchronization (SINK) component will use a file and the locking of that file to indicate when the server is ready for interfacing with the client. When the server is ready, it will create a zero length file and exclusively lock it. The client will check to see if the file exists and if the file is locked over a certain amount of time. Once the file is created and locked, the client can begin the interfacing with the server. Should the client timeout waiting for the file to be created or locked, an error will be created for the client.

     If, for some reason, the server dies, the Process Synchronization (SINK) component has an interface provided that can be used on the termination path that will destroy the file. In extreme cases where the termination path cannot destroy the file, the locking of the file will ensure that the client knows whether the server is ready or not. When the server process is terminated in an extreme case, the lock on the file will be lost. This functionality is required to be implemented by the operating system in the environment. By having the client check for the file and for the lock on the...