OK, I've been reading the example, so the only problem when using multiple
threads calling io_service::run() is the threads may use a resource at the
same time, in the example's case is the count variable and the cout stream.
If my handlers always use their own resources there will be no problems and I
can gain performance and scalability, is that right?
Here is a portion the code: http://codepad.org/oeFITS4v
It is a server that receives a command string from client, executes the
command then writes the output back (I removed ASIO_DISABLE_THREADS)
The on_read handler uses read_buffer_ and the on_write handler uses
write_buffer_, I think this is safe enough.
On the client side, after sending a command it will wait for results, so one
client won't send 2 commands at the same time, no multiple server's on_read
calling. The async_accept is not called again until the current client
disconnects, the ctlserver deals with only one client (the control client
which sends command) at a time.
Till now if I call io_service::run() in multiple threads, it's still safe.
The point is there's another server (the main server) is accepting multiple
clients (normal clients which requests service) at the same time and it runs
in the same program with the ctlserver.
Each connected client will be allocated with 1 socket, 2 buffers to read and
write, separately.
(I wrote a session class to handle client).
My worry is when serving multiple clients, sessions will access some shared
resources, reading and writing, for example database connection.
It's a pity that there's no readable code for this now because I'm still
designing the server.
Basically when a client sends a request to the server, session parses it and
creates a object (request class), request class has a method called execute().
When multiple threads call the request::execute() it may be unsafe.
So I have two options:
- Create a global strand and wrap the execute() function of any connected
session, is it acceptable? Saying: 500 clients and wrap 500 functions, sharing
one database connection.
- The data source is a MySQL server, I can let each session have its own db
connection, and I will try to assure that my application doesn't have any
shared data to be used concurently, each session is on its own and mysql
connector library is thread-safe already.
Can I have some suggestions on designing the server?
Thank you in advance.
Post by Igor RPost by Manh Nguyen TienThanks for your reply. I'm defining ASIO_DISABLE_THREADS in my application
now. Does it mean that if I discard that macro and change no code, Asio
will call my handlers in other threads automatically?
No.
ASIO_DISABLE_THREADS means that Asio disallows operations that spawn
internal threads, like async_resolve (if I'm not mistaken, such an
operation will throw boost::asio::error::operation_not_supported
exception).
Even without this macro Asio won't parallelize your completion
handlers, unless you invoke io_service::run() in multiple threads.
http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/tutorial/tuttimer5.
html
Post by Manh Nguyen TienShould I discard that macro?
That depends on your requirements and limitations. Usually there's no
reason to define this macro, unless your platform has restrictions
with regards to threads.
Post by Manh Nguyen TienIf it's still single-threaded but having timer on every operation, are
there any other benefits/pitfalls compared to multi-threaded application
besides the waiting time for the timeout handler?
1) One can invoke io_service::run() in one thread, but build w/o
ASIO_DISABLE_THREADS. This allows Asio to spawn internal threads, when
it needs to emulate asynchronous behavior, so all Asio features can be
used. Still, it guarantees that all the completion handlers get
invoked sequentially. So, from Asio user's point of view, the
application is still single-threaded, in the sense that there's no
need to provide any synchronization.
2) One can completely disable threads in Asio with the above macro. In
this case, Asio guarantees that it doesn't spawn any threads, but you
should assume that it may throw operation_not_supported exception
under some circumstances.
----------------------------------------------------------------------------
-- _______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio