Re: [Libevent-users] Thread safety with Evbuffers and Bufferevents

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Sun, Jun 20, 2010 at 5:51 AM, Avi Bab <avib@xxxxxxxxxx> wrote:
> Hello all,
>
>
>
> I’d like to use a socket based bufferevent to perform asynchronous writing
> to the underlying socket:
>
> One thread, X, adds data to the output  evbuffer (either by
> evbuffer_reserve_space+ evbuffer_commit_space or by evbuffer_add_reference)
> and another thread, Y, dispatches on the bufferevent’s event_base (i.e.,
> actually sends the data via the socket).
>
> My questions are –
>
> Does thread X need to perform locking on the evbuffer?
>
> If so then how can I have thread Y synchronize on the same locks?
>
> I assume that setting the bufferevent option BEV_OPT_THREADSAFE will not
> affect the “direct” access to  the evbuffer by X.

Setting BEV_OPT_THREADSAFE will make the evbuffers and the
bufferevents all get locks, which should work fine for most
operations.  As of Libevent 2.0, a bufferevent and the two evbuffers
associated with it all share the same lock.  (Some future version
might get smarter here; but in practice the current approach seems
good enough.)

There's one wrinkle here, though: sometimes you want a *set* of
operations on a bufferevent or evbuffer to be atomic.  For example,
even though evbuffer_reserve_space() is locked, and
evbuffer_commit_space() is locked, you still don't want another thread
modifying an evbuffer in between when you call
evbuffer_reserve_space() and evbuffer_commit_space().  You can prevent
this by calling evbuffer_lock() before you start doing the operations
you want to be atomic, and evbuffer_unlock() when the atomic
operations are finished.

Libevent 2.0.6-rc will introduce a
bufferevent_lock()/bufferevent_unlock() pair to perform the same
function on bufferevents.

yrs,
-- 
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.