You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by Alan Conway <ac...@redhat.com> on 2015/03/19 20:35:02 UTC

Thread-safety rules of proton

I don't think I'm saying anything new here, just want to confirm my
understanding of the thread-safety rules of the proton library.

Separate pn_connections can be processed concurrently in separate
threads. A given pn_connection_t must NOT be used concurrently.

All objects associated with a connection must be handled in the same
thread context that handles that connection. This is because calls on
all objects can potentially find their way back to the shared connection
object. For example you can get all the way from a delivery to the
containing connection:

pn_delivery_t *pn_work_next(pn_delivery_t *delivery)
{
  assert(delivery);

  if (delivery->work)
    return delivery->work_next;
  else
    return pn_work_head(delivery->link->session->connection);
}

The exception (I think/hope) is pn_message_t. pn_message_t does not (I
think) have any pointers to shared objects. So once a pn_message_t has
been decoded it IS ok to handle separate pn_message_t objects in
separate threads (provided any individual pn_message_t instance is never
used concurrently of course)

Is that about correct?

Cheers,
Alan.


Re: Thread-safety rules of proton

Posted by Božo Dragojevič <bo...@digiverse.si>.
I understand it this way, too

Bozzo
On Mar 19, 2015 8:35 PM, "Alan Conway" <ac...@redhat.com> wrote:

> I don't think I'm saying anything new here, just want to confirm my
> understanding of the thread-safety rules of the proton library.
>
> Separate pn_connections can be processed concurrently in separate
> threads. A given pn_connection_t must NOT be used concurrently.
>
> All objects associated with a connection must be handled in the same
> thread context that handles that connection. This is because calls on
> all objects can potentially find their way back to the shared connection
> object. For example you can get all the way from a delivery to the
> containing connection:
>
> pn_delivery_t *pn_work_next(pn_delivery_t *delivery)
> {
>   assert(delivery);
>
>   if (delivery->work)
>     return delivery->work_next;
>   else
>     return pn_work_head(delivery->link->session->connection);
> }
>
> The exception (I think/hope) is pn_message_t. pn_message_t does not (I
> think) have any pointers to shared objects. So once a pn_message_t has
> been decoded it IS ok to handle separate pn_message_t objects in
> separate threads (provided any individual pn_message_t instance is never
> used concurrently of course)
>
> Is that about correct?
>
> Cheers,
> Alan.
>
>