Could you tell me how Java can do the following things that Win32 API does?
"Open files without a system cache to read and write data"
I'm investigating, but I can't find any means at the moment.
Also, I received information that sun.nio.fs.WindowsNativeDispatcher is possible, but I gave up the package below sun because I cannot use it due to business reasons.
Thank you for your advice on this question.Add a description of why NO_BUFFERING is required.
For example, let's say that two people, A and B, performed the following tasks for a single file at approximately the same time.
①A looks at the file
②B also refer to the above file
③A updates the above files
④B refers to the above file
When referring to の, there is no particular problem as long as the contents updated by A are reflected.
However, in the unlikely event that the contents of the actual file are referring to an unreflected disk cache, B is concerned that it will end up referring to a file that does not reflect the updated contents of A (reference in the state of = 2).
Therefore, if we can refer to NO_BUFFERING, the above concerns will be resolved.
In addition, there is a possibility that exclusive control may be used to solve the problem, but due to business reasons, it is impossible to add exclusive control.
When you open a file using Java's java.io.FileInputStream, it appears that you open it using the system cache.
以下 As a result of following the source as below, it appears to be open with FILE_ATTRIBUTE_NORMAL for CreateFileWflagsAndAttributes.
publicFileInputStream(File file)throwsFileNotFoundException{ String name=(file!=null?file.getPath():null); SecurityManager security=System.getSecurityManager(); if(security!=null){ security.checkRead(name); } if(name==null){ through new NullPointerException(); } if(file.isInvalid()){ through new FileNotFoundException("Invalid file path"); } fd = new FileDescriptor(); fd.attach(this); path=name; open(name); } private void open (String name) threads FileNotFoundException { open0(name); } private native void open0(String name) threads FileNotFoundException;
JNIEXPORT void JNICALL Java_java_io_FileInputStream_open0(JNIEnv*env, jobject this, jstring path){ fileOpen(env, this, path, fis_fd, O_RDONLY); }
void fileOpen(JNIenv*env, job this, jstring path, jfieldID fid, int flags) { FD h = winFileHandleOpen(env, path, flags); if(h>=0){ SET_FD(this,h,fid); } } FD winFileHandleOpen(JNIEnv*env, jstring path, int flags) { const DWORD access= (flags&O_WRONLY)?GENERIC_WRITE: (flags&O_RDWR)?(GENERIC_READ|GENERIC_WRITE): GENERIC_READ; const DWORD sharing= FILE_SHARE_READ | FILE_SHARE_WRITE; const DWORD disposition= /* Note: O_TRUNCoverrides O_CREAT*/ (flags&O_TRUNC)?CREATE_ALWAYS: (flags&O_CREAT)?OPEN_ALWAYS: OPEN_EXISTING; const DWORD maybeWriteThrough= (flags&(O_SYNC|O_DSYNC)) ? FILE_FLAG_WRITE_THROUGH: FILE_ATTRIBUTE_NORMAL; const DWORD maybeDeleteOnClose= (flags & O_TEMPORARY)? FILE_FLAG_DELETE_ON_CLOSE: FILE_ATTRIBUTE_NORMAL; const DWORD flagsAndAttributes=maybeWriteThrough |maybeDeleteOnClose; HANDLE h = NULL; WCHAR* pathbuf = pathToNTPath(env, path, JNI_TRUE); if(pathbuf==NULL){ /* Exception already pending*/ return-1; } h = CreateFileW( pathbuf, /* Wide char pathname */ access, /* Read and /or write permission*/ sharing, /* File sharing flags */ NULL, /* Security attributes*/ disposition, /* creation disposition*/ flagsAndAttributes, /* flags and attributes*/ NULL); free(pathbuf); if(h==INVALID_HANDLE_VALUE){ throughFileNotFoundException(env, path); return-1; } return(jlong)h; }
Thank you for your cooperation.
java file-input/output
As it is not based on facts, please forgive me for the inappropriate answer.
@774RR refused to correct it, so I had no choice but to write it.
Personally, I don't think it's possible without using JNI.
I don't know if a library containing it is available on the market.
If it's disk access synchronization, I think it's file or page lock, but if it's limited to Java and there's only one node or process, I had the impression that it should be synchronized a little higher than disk access (how do you feel)?Disk caching is done by the OS and devices, and buffering is done by the app/library side.If synchronization is a problem after the operating system, it may be a file system specific specification or an OS or device bug.In any case, if you're going to answer the question, you'll have to be more specific.
NO_BUFFERING
alone cannot avoid the following scenario, so it may be useless to think about it
Logically, when one piece of data (which is supposed to be class
) happens to be stored across sectors (or clusters) m
and n
(m
and n
are separated, but it is not 0 that it is difficult to happen)
Thread 1 -------------------------------------------------------------------------
Read thread 2-m ------------------- n ---
The m read here is the old value, and the n read here is the new value.
Thread 2 reads some old, some new, or broken
Well, the situation is exactly the same as that of a 16-bit CPU that normally handles 32-bit values with a 32-bit CPU that is not atomic. So, as a general rule, "If non-atomic processing can overlap, exclusion is required." It's not that NO_BUFFERING
no longer reproduces it.
# It just so happens that with the current internal implementation of Windows, probability 0 = may not occur, but
Therefore, I would recommend that you exclude it completely.Even if you show this, if you have a boss who says, "Exclusion is prohibited because the bug that deadlocks has not been removed," Oira will doubt the development technology and the system.
© 2024 OneMinuteCode. All rights reserved.