[rabbitmq-discuss] Fwd: C client and thread safety

Jim Irrer irrer at umich.edu
Fri Jul 2 17:26:27 BST 2010

Tony -

Thanks, that really helps.

- Jim

Jim Irrer     irrer at umich.edu       (734) 647-4409
University of Michigan Hospital Radiation Oncology
519 W. William St.             Ann Arbor, MI 48103

---------- Forwarded message ----------
From: Tony Garnock-Jones <tonyg at lshift.net>
Date: Thu, Jul 1, 2010 at 8:39 PM
Subject: Re: C client and thread safety
To: Jim Irrer <irrer at umich.edu>
Cc: rabbitmq-discuss <rabbitmq-discuss at lists.rabbitmq.com>

Hi Jim,

Jim Irrer wrote:
> I'm working with the RabbitMQ C client, and had a few questions
> about thread safety.

In general, there is no thread awareness built in to librabbitmq at all. It
currently the responsibility of applications using the library to ensure
multiple threads don't screw up the library's state.

That said, there is no longer any global state at all in the library, so if
stick to one connection (and thus one socket) per thread, you should be

> Must a socket returned by amqp_open_socket be exclusively
> associated with one connection, or can it be used for multiple
> connections?

One connection. Each AMQP connection needs exactly one socket to communicate

> Must a socket returned by amqp_open_socket be exclusively
> used by one thread, or can it be used by multiple threads?

The connection associated with the socket must be used by one thread *at a
time*. The locking can get quite complicated when you take into account the
librabbitmq currently deals with incoming events, so sticking with one
connection for each thread makes life much easier.

> Must a connection returned by amqp_new_connection be exclusively
> used to read from or write to one channel/queue, or is using multiple ok,
> even in a multi-threaded environment.

Multiple are OK, but again, each connection is best kept to a single thread.
Think of multiple channels as separate *transaction* and *error reporting*
contexts; they don't buy much else in current versions of the AMQP protocol

> If any of these can be used by multiple threads, is there a performance
> advantage in reusing the same socket or connection, or is using multiple
> ones better?

Using a single connection with multiple channels means that TCPs
congestion-avoidance counts all AMQP traffic as a single stream, whereas
multiple connections with a single channel each means that TCP will count
stream separately. Which is more appropriate to your application depends on
structure of your network: the former might be more appropriate for a WAN
the latter for a LAN or a datacentre, etc.

> It looks like channels (created with amqp_channel_open) are identified
> by (small?)
> integers chosen by the application and are associated with the
> connection.  This
> means that it is the responsibility of the application to choose unique
> numbers,
> properly close them, etc..   It would seem cleaner to pass a connection as
> single parameter to amqp_channel_open and have it return a pointer to a
> channel,
> and the list of channels would be maintained in the connection.

Yes, there is a lot of per-channel state management the library currently
doesn't do. A set of "active" channel numbers might not be too hard to

> Also, it looks like amqp_new_connection uses 'calloc' to allocate
> memory for a connection, but amqp_connection_close does not do
> a 'free' to avoid the memory leak.  Maybe that was intentional, but if
> not it should be changed.

The amqp_connection_close() function causes an AMQP Connection.Close RPC to
happen on the open socket, but does not then tear down any of the
state: that's what amqp_destroy_connection() is for. The relevant pairings

For local connection state management (calloc/free):

For remote connection state management (Connection.Open/Tune/Close, once
connection state exists):
...plus interactions required on receipt of a Connection.Close method frame
from the peer.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100702/49e51671/attachment-0001.htm>

More information about the rabbitmq-discuss mailing list