On 30/07/2009, Pavel Shevaev wrote:
> * 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
Do several threads share the results, or is each set of results only
used by the thread that registered the query? If each result is only
used by one thread it should be possible to avoid the races.
> 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?
Yes and yes.
> 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?
If the application thread that issued the query copies all the results
while holding a mutex lock, and the database thread doesn't hold on to
the results, then the reference-count updates should be race-free.