I am working with the 4.4.12-rt19 RTLinux kernel patch.
I have a realtime application written in C that has separate processes running on separate cores taking in data from the network, computing on that data, and then logging results. I am attempting to log on the order of 10KB per ms tick of data to file.
The logging process has access to all of the incoming data in shared memory. Right now, I am using sqlite3 and sqlite3async to buffer the database to memory in one thread of the logging process and then commit the in-memory instance to file every second with a call to sqlite3async_run().
The problem is that during part of the sqlite3async_run() execution, the sqlite3_step() command to write to the in-memory database buffer hangs and violates my 1ms timing guarantee.
I am not sure if the error is happening because of how threaded processes work in a realtime environment or because of how sqlite3async works. As far as I can tell, sqlite3async is supposed to be able to buffer the database in memory using the sqlite3 virtual file system and then handle the actual file write with a background thread (as detailed here). I have tried changing the scheduling priorities and nicenesses of each thread to no avail.
Any help or suggestions would be greatly appreciated!
Using sqlite3async does not remove the delays associated with writing; it just defers them until later, when you can afford them.
Consider using WAL mode. There, you have the same delay when doing a checkpoint, but the WAL is stored on disk, so you can defer the checkpoint for arbitrary long times without running out of memory (at the cost of the WAL becoming arbitrarily large).
If writing in WAL mode is still too slow, you have to implement your own FIFO, and let another thread continuously empty it. (If that thread moves the data out of the FIFO before actually writing, the FIFO is never locked for a long time.)