Multi-thread usage of SQLite memory databases

Attach of SQLite Memory Database
I have inserted 10 million pieces of data into the memory database a. I want to import a to a physical file B (with the same table structure). Should I use the attach command? Is there anyone else to give me a detailed explanation?
Sqlite3_open (": Memory:", & dB );
...
Ret = sqlite3_exec (dB, "create table new_table1 (ID integer primary key autoincrement, name vchar (32)", 0, 0, & zerrmsg );
Ret = sqlite3_exec (dB, "begin transaction", 0, & zerrmsg );
Ret = sqlite3_exec (dB, "insert into new_table1 (name) values ('000000');", 0, 0, & zerrmsg );
Ret = sqlite3_exec (dB, "Commit transaction", 0, & zerrmsg );
To this end, the database has been inserted into the memory database, and then how to import the physical file B?
Sqlite3_open ("C:/a. dat", & dB );
Ret = sqlite3_exec (dB, "attach a. dat as new_db2", 0, & zerrmsg );
Ret = sqlite3_exec (dB, "insert into new_db2.new_table2 (name) values ('name')", 0, & zerrmsg );
Ret = sqlite3_exec (dB, "detach new_db2", 0, & zerrmsg );
If (Ret! = Sqlite_ OK)
MessageBox ("An error occurred while appending the database! ");
An error occurred while appending the database! ", I don't know where the error was written...

In this case, attach the file database to the memory database. Sqlite3_open ("C:/a. dat", & dB );
This sentence is redundant and should be removed.
Ret = sqlite3_exec (dB, "Attach 'C:/a. dat 'As new_db2", 0, 0, & zerrmsg );
In this way, you can copy data from the memory database to the file database. If there is no table in the file database (note that the new table has no index ):
Create Table new_db2.new_table1 as select * From new_table1;
When tables exist:
Insert into new_db2.new_table1 select * From new_table1;

Already done ~
Ret = sqlite3_exec (dB, "Attach 'C:/a. dat 'As new_db", 0, 0, & zerrmsg );
Ret = sqlite3_exec (dB, "begin transaction", 0, & zerrmsg );
Ret = sqlite3_exec (dB, "insert into new_db.new_table2 (name) Select name from new_table1", 0, & zerrmsg );
Ret = sqlite3_exec (dB, "Commit transaction", 0, & zerrmsg );
3 million pieces of memory data and 10 fields are written into approximately MB physical files.

There are no multi-thread write operations. Thread A does not stop reading and thread B writes/modifies it at a certain time!
A starts first and starts later than B. However, since thread a reads a piece of data randomly from 0.5 million pieces of data every 20 milliseconds, the query interval is very short (20 ms ); at this time, line B writes 10 thousand pieces of data, and then randomly modifies 20 thousand pieces of data. B is always successful, but at the same time that B operates, A is almost always in the busy state, most queries (20 ms) return the busy status and occasionally query a value (it is estimated that a data entry is successfully written/modified in line B, when the gap between Data Writing and modification is not started), thread B writes/modifies the data, and thread a immediately becomes normal.
Three conclusions are drawn:
1. read/write mutex (LOCK) exists in any database, Oracle/sqlserver/MySQL/SQLite...
2. You can modify the source code of SQLite. Sleep or a prompt is prompted when thread read/write is mutex (sqlite3_busy_timeout and sqlite3_busy_handler functions have been added to the new SQLite lib version)
3. When the CPU computing power is strong, the probability of mutual exclusion will be reduced, but the mutual exclusion will not disappear, because the occurrence of the mutual exclusion lock is to ensure data integrity, remember!