List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:July 30 2009 9:19am
Subject:Re: Proper usage of mysql++ in a multi-threading environment
View as plain text  
On Jul 30, 2009, at 1:04 AM, 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)

Not being a game programmer myself, I could be talking out of a  
suboptimal orifice, but I can't help but ask: does it make sense to  
use a disk-backed, IPC-fed relational database during game play in the  
first place?  I can see using MySQL to store information about games  
and players long-term, but I would imagine this would all be loaded up  
on startup, manipulated in memory during play, and the changes not  
flushed back to disk until play concludes.

The most aggressive I can imagine being on data concurrency in an  
application like that would be periodic saves of in-progress game data.

If you're trying to coordinate multiple CPUs through the database, I'd  
switch to some other mechanism, like a separate coordination server  
which sends out play update packets over UDP/IP.

> * 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

Given the requirement to put live data in such a hard-to-reach place  
-- disk-backed, and across an IPC link -- this is a sensible design.

> Since, I believe, making RefCountedPointer thread safe can be
> expensive and not quite appealing to the original authors of mysql++

You surmise correctly.

Throwing more threads -- and cores to back them up -- at a database  
access problem isn't going to make it faster, so there's no point in  
MySQL++ itself offering a baked-in thread safety strategy.

A program using MySQL++ may be able to use multiple cores efficiently  
by throwing non-DB work at them, as in your case.  In that case, you  
already have to come up with your own synchronization strategy, so you  
still wouldn't want MySQL++ offering an alternate strategy that could  
clash with your design.

The most I could imagine MySQL++ doing is offering a peripheral  
prepackaged strategy; say, a message-passing mechanism a la Erlang.   
It would be like ConnectionPool, totally optional, with no interaction  
with the internals of MySQL++ at all.  Something you could write  
yourself, with no need to dive into the MySQL++ code.  (Hint.)

Embedding such a strategy deeply into MySQL++ would certainly be the  
wrong thing.

> 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?

Yes, that's what I would do; copy the row data into a non-MySQL++ data  
structure as soon as you can, and pass *that* between the threads, so  
the MySQL++ data structure can be released by the thread that created  

Personally, I'd use STL containers of SSQLSes[*].  Query::storein()  
creates a data structure with no links into the MySQL++ internals.   
All MySQL++ data structures are created and destroyed within that  
single method call, so you should be able to pass off the container to  
the other thread as soon as it's created.

[*] Yes, SSQLS is a MySQL++ feature, but I'm not considering it a MySQL 
++ data structure here because they're user-defined, only loosely  
coupled to the MySQL++ internals, and the C API has no concept of them  
at all.  Plus, it's the copy that counts here, not so much what you  
copy it *to*.
Proper usage of mysql++ in a multi-threading environmentPavel Shevaev30 Jul
  • Re: Proper usage of mysql++ in a multi-threading environmentJonathan Wakely30 Jul
    • Re: Proper usage of mysql++ in a multi-threading environmentPavel Shevaev30 Jul
  • Re: Proper usage of mysql++ in a multi-threading environmentWarren Young30 Jul