0
...
options["OPT_WRITE_TIMEOUT"] = timeout;   
std::lock_guard<std::recursive_mutex> locker(mutex_); 
auto driver = sql::mysql::get_driver_instance();
connection_.reset(driver->connect(options));
...

This code is being executed in a single thread. It's like a connection thread.

All what I want is to halt this connection during the process of establishing a connection to start a new connection, say, with new changed options. Mustn't there be a safe way to do that or I'm doomed to wait until the current connection attempt has exceeded the timeout?

Greezlock
  • 13
  • 3
  • Can't you let this thread run to completion while you start another thread to attempt another connection with new parameters? – Mike Nakis Sep 12 '18 at 12:04
  • @MikeNakis I thought that "sql::mysql::get_driver_instance()" could create the only "driver" instance (like a singleton) and because of that I had to create only one new connection simultaneously by protecting the process with a mutex. So I can just protect only the "sql::mysql::get_driver_instance();" method with the mutex and then start creating a new connection without any mutexes, right? P.S. I don't know what made me think that the "connect" method must have been protected with a mutext as well :/ – Greezlock Sep 12 '18 at 12:22
  • okay, I do not know about that. I find it hard to believe that either `get_driver_instance()` or `driver->connect()` need protection against re-entrance, but I do not really know. – Mike Nakis Sep 12 '18 at 17:02
  • @MikeNakis as its [documentation](https://dev.mysql.com/doc/connector-cpp/1.1/en/connector-cpp-examples-connecting.html) says that the only thing we need is to avoid calling this function simultaneously by several threads. But now I'm really in doubt whether we need to call it every time before starting a connection (this resembles an initialisation of the driver).What if it has to be called only once with a mutex protection and there is no any need to call it again any more?It would make my code easier and more pleasurable,to be honest. Any ideas how I could get known about it exactly?Thanks! – Greezlock Sep 12 '18 at 17:33

1 Answers1

0

So, the documentation of get_driver_instance() says that you must not simultaneously invoke it from multiple threads. I suppose that's because the first time it is invoked it will create the driver, so re-entrance of that method may result in the creation of multiple instances of the driver. That's all very fine, because you can invoke this method during the static initialization of your program, outside of any spawned threads, so there is no need to guard it with a mutex. So, you obtain the driver once and store it for use by the rest of your program.

The documentation of driver->connect() does not say that it is not re-entrant, so it probably is re-entrant. This means that you can spawn one thread to try and connect, and spawn additional threads which also try to connect with different parameters.

So, you should not need a mutex anywhere. If for some reason you really don't want to obtain the driver once and store it for later use, then you can make use of the mutex to guard against re-entering the call to get_driver_instance(), but you do not (and should not) use the mutex to guard against re-entering the call to driver->connect(). Thus, you will be able to invoke driver->connect() in parallel from multiple threads.

Incidentally, get_driver_instance() should return immediately; it is the driver->connect() call which may take a long time.

Mike Nakis
  • 56,297
  • 11
  • 110
  • 142