This is the mail archive of the ecos-patches@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Patch for Finer Grained locking in File I/O package


Here is the proposed set of changes to address the issue I outlined below and discussed with Nick Garnett. What is attached is an edited version of the needed file (packages/io/fileio/fd.cxx) modified based off a recent eCos "current" CVS tree snapshot and the original unmodified file. I apologize for not providing in a more conventional RCS/CVS diff format, but I do not use RCS/CVS for revision control.

Regards,
Jeff

jrs at inscitek dot com

Original dicussion email:

I have noticed a "problem" in the eCos fileio package (packages/io/fileio)
relative to what amounts to rather "coarse grained" mutex protection during
a file close() operation.

Background: When the last open'ed file descriptor on a particular file
object is closed via close() implementation in the file
io/fileio/src/io.cxx, a call to cyg_fd_free() is required to deallocate the
file descriptor and the file object. Since in this case, this is the last
reference to the file object, the file system's fo_close() method is also
called. This entire operation here is undertaken in the context of holding
the system wide file descriptor lock named "fdlock". See
io/fileio/src/fd.cxx implementation of cyg_fd_free().

The side of effect of this is while any file system's fo_close() operation
is taking place ANY file descriptor operations (system wide) will be blocked
waiting for the pending close to complete....no matter what device or
filesystem the I/O is associated with. Since I/O device interactions are
likely required during say a disk based file operation, it is possibly
and/or likely that all I/O operations in the entire system that work through
file descriptors will blocked during this time period.

I think this operation needs a much more finer grained mutex locking
strategy.

My initial thought is that file object's reference count (f_ucount), in
principle, should be protected by the file object's own mutex, not by the
system wide "fdlock" mutex. This will allow the file-system's fo_close()
method to be invoked w/o still needing to hold the fdlock mutex, thereby
allowing all other file descriptors to operate concurrently with the close
operation.

I believe the set of changes needed would be isolated to the
io/fileio/src/fd.cxx module.

Attachment: fd.cxx_orig
Description: Binary data

Attachment: fd.cxx_new
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]