5

There are many examples on the net about creating a simple thread pool such as Sample1 and Sample2

What I wanted to implement though is to have a separate thread pool for different tasks. For example, the app may have a pool of threads for processing incoming tcp connections (let's call this the network pool), while another pool for talking to a database (database pool).

These incoming tcp requests might want information from the database. In this case it will need to ask the those threads from the database pool to perform query, and return the result asynchronously.

Is there a recommended way to do so using boost::asio? Would it be having one instance of io_service for each pool? And how should those threads communicate with each other (using boost)?

I understand to explain all these, the code won't be that short and trivial, but if possible some sort of pseudo code would be much appreciated.

Thanks!

Community
  • 1
  • 1
TDL
  • 103
  • 6
  • 2
    IMO, the simplest way is to put every pull on a separate `io_service`. To communicate, `post` functors between these `io_service`s (note however that you can't know which thread will process your post). – Igor R. Jan 12 '14 at 10:53

1 Answers1

2

The communication between thread / thread pools should be through thread safe queues.

In your example, you should have a networking thread pool for handling network connections, a process pool for executing the network requests, and a database connection / thread pool (one pool per database; one thread per database connection, but possibly you could have multiple connections to the same database).

You would also need a thread safe queues, one for the network pool, one for the process pool and one for each of the database pools.

Say you have a network request that needs to get information from the database. You would receive the request while executing on a network thread, and append the handler for the request onto the process queue.

The process handler (in a process thread) would see that the request needs something from the database, and so it would append a database request as well as a callback handler onto the appropriate database queue.

The appropriate database thread would pick up the request from the database queue, execute the query, get the results back, and add the results to the callback handler. The callback handler object with the database results would then be pushed onto the process queue.

The callback handler (in a process thread) would then continue executing the request, and possibly package a response message, which is then pushed onto the network queue.

The network handler (in a network thread) would then pick up the response messsage and deliver it (encoding as necessary).

An example of a thread safe queue can be found here.

Albeit a little complicated, you can see an implementation of an application server that can handle what you're talking about here, although it may be overkill for what you're trying to do. The source code is fairly well documented so you should be able to follow it and see what it's doing.

My example uses boost for asio (see the TCP Connection implementation within that same system), but it does not use boost io_service for handlers.

Tony Richards
  • 391
  • 3
  • 5
  • Thanks and sorry for the late response. Got a question. From your example, you have three pools (network, process, database). Will it work as well if there are only two pools, so that the network pool will talk to the database pool directly via some sort of thread safe message queue, using the same mechanism you have described? Thanks again. – TDL May 25 '14 at 06:51