Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

External timeouts can cause bad lock states in multithread environment #16

Open
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants

Hey Mike, hope all is well.

Consider the snippet:

Timeout.timeout(n) do
... some stuff ...
memcache_client.get(some_key)
... more stuff ...
end

That can cause a timeout exception to be raised in with_socket_management after @mutex.lock is called, but before execution has entered the begin block, and thus the ensure block won't run and the mutex won't be unlocked.

Solution is simply to put the lock inside the begin block with an additional guard.

-- C

Owner

mperham commented Mar 21, 2011

Hey, dude!

Interesting. BTW I'm no longer supporting memcache-client. You'll need to
fix it yourself or switch to Dalli.

On Mon, Mar 21, 2011 at 3:28 PM, cjbottaro <
reply@reply.github.com>wrote:

Hey Mike, hope all is well.

Consider the snippet:

Timeout.timeout(n) do
... some stuff ...
memcache_client.get(some_key)
... more stuff ...
end

That can cause a timeout exception to be raised in with_socket_management
after @mutex.lock is called, but before execution has entered the begin
block, and thus the ensure block won't run and the mutex won't be unlocked.

Solution is simply to put the lock inside the begin block with an
additional guard.

-- C

Reply to this email directly or view it on GitHub:
#16

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment