[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

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.

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