Guys, thanks for the excellent library, it's just great!
I have a question regarding proper usage of mysql++ in a
multithreading application for the following scenario:
* an application thread is not allowed to make any queries to database
since it's quite expensive(it's a game with very strict time budget
for each frame)
* the application thread is allowed to register async. queries in the
dedicated database thread
* the dedicated database thread has a queue of requests, once the
concrete request is executed and ready the callback is fired and other
threads can retrieve execution results
I implemented all of the said above using mysql++ with connection pool
as shown in the manual. However, I'm experiencing problems with
sharing mysql++ data structures(namely Row objects) across threads and
the manual mentions about possible issues which may arise.
I think the main problem is IMHO a non-thread-safe implementation of
RefCountedPointer. The hellgrind shows clearly there is a datarace:
==21259== Possible data race during read of size 4 at 0x5dbeba8 by thread #8
==21259== at 0x4B1F567:
mysqlpp::RefCountedPointerDestroyer<mysqlpp::FieldNames> > const&)
==21259== This conflicts with a previous write of size 4 by thread #6
==21259== at 0x80F1F85:
==21259== by 0x811E445: mysqlpp::Row::~Row()
Helgrind may show false positives if some non-posix-threads technique
is used(e.g some lock free algorithm), however looking at the
implementation of RefCountedPointer it's quite obvious(please correct
me if I'm wrong) that there is no thread synchronisation at all.
Is it a known issue? Is it done on purpose?
Since, I believe, making RefCountedPointer thread safe can be
expensive and not quite appealing to the original authors of mysql++
I'm currently thinking about sharing my own very simple Row
implementation across threads which would be created by copying
mysql++ Row data in the database thread. What do you think about it?
I'm using mysql++-3.0.9 built from source with thread awareness on linux x86.
Thanks in advance.
Best regards, Pavel