United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4823133 RandomAccessFile.length() is not thread-safe
JDK-4823133 : RandomAccessFile.length() is not thread-safe

Details
Type:
Bug
Submit Date:
2003-02-24
Status:
Open
Updated Date:
2008-11-19
Project Name:
JDK
Resolved Date:
Component:
core-libs
OS:
solaris_7,windows_xp
Sub-Component:
java.io
CPU:
x86,sparc
Priority:
P4
Resolution:
Unresolved
Affected Versions:
1.4.1,5.0
Targeted Versions:

Related Reports
Relates:

Sub Tasks

Description
Name: nt126004			Date: 02/24/2003


FULL PRODUCT VERSION :
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)


FULL OPERATING SYSTEM VERSION :
SunOS pantar 5.7 Generic_106541-17 sun4u sparc SUNW,Ultra-4

EXTRA RELEVANT SYSTEM CONFIGURATION :
System has 4 CPUs.

A DESCRIPTION OF THE PROBLEM :
The length() method of java.io.RandomAccessFile temporarily
changes the file pointer.  If it is called in one thread,
another thread that does a read() or write() can do so at
the wrong offset.  Conversely, a seek() in another thread
can be lost due to a simultaneous call to length().

This should either be clearly documented in the API
specification (requiring users to synchronize calls to
length() with those to other file methods) or fixed using
some kind of internal lock.


REPRODUCIBILITY :
This bug can be reproduced occasionally.

CUSTOMER WORKAROUND :
synchronize all calls to relevant methods on some object,
e.g. the RandomAccessFile instance itself.
(Review ID: 181612) 
======================================================================

                                    

Comments
EVALUATION

The implementation of RandomAccessFile.length() does three seeks: 
 
  1.  seek to save the current file position 
  2.  seek to the end to obtain the offset of the end of the file (the  
      returned length) 
  3.  seek to the saved file position to reset the original file 
      pointer position 
 
Naturally, in a multithreaded scenario, this could cause problems if other seek operations are occuring in other threads.  Locking all operations on RandomAccessFile would cause performance problems so it would be more desirable to find native APIs that can retrieve this length atomoically.   
 
A possible candiate for unix is the st_size field in the stat structure returned by fstat.  Potential problems may be that this value does not properly handle sparse files on all systems or the data type of st_size does not correctly support files of length > 4G. 
 
For windows, GetFileSize will return the total size including the sparse regions, which is what the current implementation effectively does.
                                     
2005-11-16
EVALUATION

I agree with the above analysis.  
length() can be made more thread-safe, without performance penalty,
on at least some operating systems.
This is a defect, not an rfe.
                                     
2006-02-12



Hardware and Software, Engineered to Work Together