Database record I/O and thread safety

You can use the I/O feedback area of a database file to communicate results of I/O operations to the record I/O user. A typical application might have problems with thread safety because of the nature of the feedback area.

When you perform an I/O operation, the support of the run time and of the database ensures that the I/O operation is threadsafe. When the I/O is complete, any locks that the run time holds are released and control is given back to the application.

It is the application's responsibility to serialize access when examining the I/O feedback area so that another thread does not use it simultaneously. COBOL and RPG use the feedback area on every I/O operation, so if you do I/O to the same shared file with different languages, you should serialize access to the file even when you are not apparently using the feedback area.

For example, Thread 1 is using file A for record I/O operations. The system stores information about those operations in the feedback area for file A. After the I/O operation for Thread 1 completes, Thread 1 manipulates the feedback area by examining fields in the feedback area. If it does not protect the feedback area when Thread 2 uses file A for record I/O operations, the system uses the same feedback area. Thread 1 may get inconsistent results because Thread 2 is using the feedback area at the same time. This occurs when sharing a file is conducted by the use of the file pointer or file descriptor number. It is not a problem if the file is opened in each thread.

You should use a synchronization technique to protect the feedback area so that other application code or the system does not change it when it is being accessed.

Related reference
Database considerations for multithreaded programming