[issue12352] multiprocessing.Value() hangs

[greg.ath]

greg.ath gathan...@gmail.com added the comment:

Hi,

I also wonder about the performance cost of a recursive lock.

I am still unable to reproduce the bug in a simple script. Looking
closely to the gdb stack, there is that frame:
Frame 0x13be190, for file /usr/lib/python2.6/multiprocessing/heap.py, line 173
I understand that python reuses only the beginning of a memory block,
so it frees the remaining of the block.
I use both Value(c_int) and Value(c_double), which have different
sizes. That may explain that behaviour.

in heap.py, in the malloc function:
167 self._lock.acquire()
168 try:
169 size = self._roundup(max(size,1), self._alignment)
170 (arena, start, stop) = self._malloc(size)
171 new_stop = start + size
172 if new_stop  stop:
173 self._free((arena, new_stop, stop))

Thanks for your help

2011/6/21 Charles-François Natali rep...@bugs.python.org:

 Charles-François Natali neolo...@free.fr added the comment:

 The obvious solution is to use a recursive lock instead.

 Note that it's not really a solution, just a workaround to avoid
 deadlocks, become this might lead to a corruption if free is called
 while the heap is in an inconsistent state. I have to think some more
 about a final solution, but I'd like to check first that this is
 really what's happening here.

 --

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue12352
 ___


--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12352
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12352] multiprocessing.Value() hangs

[greg.ath]

New submission from greg.ath gathan...@gmail.com:

Hi,

My multithreaded application uses multithreading.Value() to ensure thread-safe 
operations on shared data.
For unexpected reasons, after some change in my code, the function will 
consistently hang.

I did a gdb backtrace of the hanging process, and I discovered that the 
multiprocessing.head.py tries to acquire twice a same non recursive lock.
The first aquire is done in the malloc function:
#61 call_function (f=
Frame 0x13be190, for file /usr/lib/python2.6/multiprocessing/heap.py, line 
173, in malloc (self=Heap(_stop_to_block={}, _lengths=[], _lock=thread.lock 
at remote 0x7f00fc770eb8, _allocated_blocks=set([...

The second aquire is done in the free function:
#3  0x004a7c5e in call_function (f=
Frame 0x1662d50, for file /usr/lib/python2.6/multiprocessing/heap.py, line 
155, in free (self=Heap(_stop_to_block={}, _lengths=[], _lock=thread.lock at 
remote 0x7f00fc770eb8, _allocated_blocks=set([...

I don't understand the link between these two method calls, so I am unable to 
write an easy script to reproduce the problem. I would say that some garbage 
collection was done within the malloc, which called the free.


Python 2.6.5
Linux dev 2.6.32-25-server #45-Ubuntu SMP Sat Oct 16 20:06:58 UTC 2010 x86_64 
GNU/Linux

--
components: None
files: gdb_stack.txt
messages: 138506
nosy: greg.ath
priority: normal
severity: normal
status: open
title: multiprocessing.Value() hangs
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file22393/gdb_stack.txt

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12352
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com