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

RE: [Libevent-users] deadlock in libevent-2.0.5-beta



Apologies – this seems to be incorrect

 

From: owner-libevent-users@xxxxxxxxxxxxx [mailto:owner-libevent-users@xxxxxxxxxxxxx] On Behalf Of Avi Bab
Sent: Sunday, July 04, 2010 2:04 PM
To: libevent-users@xxxxxxxxxxxxx
Subject: RE: [Libevent-users] deadlock in libevent-2.0.5-beta

 

 

Prior to this modification the deadlock occurred when the thread that deletes events from the event_base had consumed ~100% CPU (each thread has a dedicated CPU).

Now it happens when the thread that adds events to the event_base consumes ~100% CPU.

 

Avi

 

 

From: owner-libevent-users@xxxxxxxxxxxxx [mailto:owner-libevent-users@xxxxxxxxxxxxx] On Behalf Of Avi Bab
Sent: Sunday, July 04, 2010 1:41 PM
To: libevent-users@xxxxxxxxxxxxx
Subject: RE: [Libevent-users] deadlock in libevent-2.0.5-beta

 

 

This made a great improvement – the deadlock still appears but only on  even higher loads.

 

Thanks,

Avi

 

 

From: owner-libevent-users@xxxxxxxxxxxxx [mailto:owner-libevent-users@xxxxxxxxxxxxx] On Behalf Of Zhou Li
Sent: Saturday, July 03, 2010 9:11 AM
To: libevent-users@xxxxxxxxxxxxx
Subject: Re: [Libevent-users] deadlock in libevent-2.0.5-beta

 

I met such deadlock too. It happened under very high load just as you said. I think the cause is that the call write(th_notify_fd[1]) got blocked ( sorry I didn't remember the exact position of this call to write th_notify_fd).

 

In event.c line 2597:

 

    /*

      This can't be right, can it?  We want writes to this socket to

      just succeed.

      evutil_make_socket_nonblocking(base->th_notify_fd[1]);

    */

 

When I uncommented this block of code, the deadlock disappeared.

 

 

On Sat, Jul 3, 2010 at 1:48 AM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:

On Thu, Jul 1, 2010 at 6:44 AM, Avi Bab <avib@xxxxxxxxxx> wrote:
>
>
> Running on Linux with pthreads.
>
>
>
> One thread (CBTcpProxyListenerThread below) adds bufferevents (with option
> BEV_OPT_THREADSAFE) to an event_base.
>
> A second thread (CBTcpProxySenderThread) dispatches on the event_base.
>
>
>

> bufferevents are removed from the event_base either by a third thread or by
> the CBTcpProxySenderThread by calling bufferevent_free (without calling
> bufferevent_disable first – is this a misuse?).
>
>
>
> The deadlock happens on pretty high load: ~6000 bufferevents are added and
> removed per second. Each one is triggered for write ~10 times per seconds
> (which gives ~60,000 triggeres per-second).


The stack traces look like they aren't the whole story.  It seems the
two threads you listed are both trying to acquire the lock for the
event base, and blocking on it..  But what's the stack of the thread
that's actually holding the lock?

--
Nick

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