EldoS | Feel safer!

Software components for data protection, secure storage and transfer

No local buffered I/O applies only to thread that does Callbacks?

Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.
#21974
Posted: 10/12/2012 12:31:07
by Rich Van Gaasbeck (Standard support level)
Joined: 12/07/2010
Posts: 11

The restriction not to do buffered I/O to the local file systems applies only to the thread that registered the callbacks? (Or perhaps the callbacks don't run on the original thread?) And only while within the callback?

Regardless, other threads that do buffered I/O within the same application should be ok, correct? But having a callback handler wait on a semaphore held by another thread that *is* doing buffered I/O could deadlock?

In otherwords this is not allowed?

Thread 1:
grab semaphore X
do buffered I/O
release semaphore X

In the OnReadFile (running in thread 2, or no-thread if that's how callbacks work):
grab semaphore X
service the read
release semaphore X
#21975
Posted: 10/12/2012 13:10:29
by Volodymyr Zinin (EldoS Corp.)

Unfortunately it isn't allowed to do so. It causes a deadlock in the system. Maybe not immediately but it eventually occurs.
The reason is in the system code. At least there is one in the system cache manager. Below are actions that cause deadlock:
1. The file system mounted over a virtual CallbackDisk disk caches some file (cache is supported by the system cache manager).
2. The cache manager in some time decides to flush the cached data for the file and it sends a "write" request to the file system. But before the "write" request is sent the cache manager locks some internal global resource!!!
3. The file system calculates where the file data is located on the disk and sends a "write" request to CallbackDisk.
4. CallbackDisk calls the OnWrite callback where the __cached__ write call is occurred and is sent to another file system.
5. This file system sees that it's the __cached__ call and, instead of sending it directly to the underlying disk, sends it to the system cache.
6. Sometimes the system cache manager decides to start flushing of this file's data immediately and tries to acquire the same global resource as above!!! But because now it's another thread (CallbackDisk uses separate thread to call the callbacks as well as the file system also can process the request asynchronously by the use of its internal worker thread) the resource can't be acquired and the thread starts waiting forever.
#21976
Posted: 10/12/2012 13:14:48
by Volodymyr Zinin (EldoS Corp.)

BTW: If it's required for you to have cached I/O inside the callbacks then perhaps use another product of us - CallbackFS. It allows cached I/O.

Reply

Statistics

Topic viewed 2510 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!