thread.error: release unlocked lock

Tim Peters tim.peters at
Fri Nov 19 00:26:40 CET 2004

[John P.Speno]
> So you have this problem, and you decide to use threads to solve it...
> System is Python 2.3.3 on Solaris 9.
> I'm using the classic Python thread model. Main thread puts stuff into
> a Queue.Queue() and worker threads get stuff out of it and do their
> thing.

A bounded queue or an unbounded queue?  Blocking get/put or
non-blocking get/put?  About how many items are in the queue?  Since
nobody has reported your symptom before, some detail or other is going
to be important.  How do the standard test_thread, test_threading, and
test_queue tests fare on this box?  Was this Python configured to use
pthreads or native Solaris threads?

> On occaision, I get an exception in the main thread when it tries to
> put something into the Queue.
>   File "/usr/local/bin/", line 47, in fragnap_it
>     work_queue.put((foo, bar, baz))
>   File "/usr/local/lib/python2.3/", line 106, in put
>     self.fsema.release()
>   thread.error: release unlocked lock
> Seems like a bad thing, and I'm not sure what can be done. Should I
> catch the thread.error and retry the put()? Or just give up and
> shutdown nicely?  (Or quickly finish the twisted version of this code?)
> Any idea on the underlying cause of this exception?

Something has gone insane -- this should be impossible.  fsema is a
mutex.  put() always acquires fsema.  Before it exits, put() releases
fsema again (unless the queue is bounded and put() has just filled
it).  The error you're seeing is the mutex complaining about an
attempt to release it when it's not in the acquired state (which
should be impossible because put() acquires fsema before this point).

More information about the Python-list mailing list