On Jan 12, 8:04 am, [EMAIL PROTECTED] wrote:
> On Jan 11, 5:26 pm, Paul Rubin <http://[EMAIL PROTECTED]> wrote:
>
> > [EMAIL PROTECTED] writes:
>
> > 1. Put a single thread in charge of the list, and communicate with it
> > by message passing through Queues. To get X out of the list, you'd
> > send the mutator thread a message asking for removal. The mutator
> > thread would loop reading and processing messages from the queue,
> > blocking when no requests are pending. This is sort of the preferred
> > Python style and is pretty simple to get correct, but if there are
> > many such objects you can end up with more threads than you really
> > want.
>
> I've heard this called 'fire and forget'. You can insure that
> mutations are honored one-at-a-time and in the order received. How
> do you make a -read- operation; wait for queued mutations, that is
> lock for a turn on the queue? Can you optionally read whatever the
> state is, regardless of what's happened in the meantime? Thing is,
> one thread needs its -own- preceding operations completed before a
> reading operation.
Brainstorm.
First, isolation of problem: Terminates at 2000 or so, on my
computer.
import thread
import time
import random
counter= 0
def simplecounter():
global counter
ret= counter
counter+= 1
time.sleep( random.uniform( 0, .001 ) )
return counter
glist= []
def th3():
while 1:
ret= simplecounter()
glist.append( ret )
print ret,
assert glist== range( 1, len( glist )+1 )
thread.start_new_thread( th3, () )
time.sleep(1)
thread.start_new_thread( th3, () )
time.sleep( 1000 )
Second, the thoughts: 'with a.callbacklock():' looks best currently.
'''multithreading ideas:
1. Put a single thread in charge
a.k.a. fire and forget.
- Lots of extra threads
+ But most are blocking most of the time
+ honored one-at-a-time, and in order received
+ ...optionally including read-access, blocking on
to get return values
a. synchronous callbacks, for read-access
+ multi-step, user-definitionized operations
- one consumer can hang an entire object
i. with a.callbacklock():?
+ only call acquire() from curr. thread, enqueue
lock obj., released from producer thread "soon"
using message-queue semantics
b. mini-transaction, guarantees all and only
consumer's ops occur in succession
- can't do anything amidst an indivdual locking
- no multi-step ops
2. Lock mutation and/or all operations
a. Locker.op
b. with Locker.withop
- In Python, other programmers always have access
to your data; nothing guarantees they'll use "with locker"
+ User-definitioning quite easy
3. @mutation decorator
def mutation( func ):
def newfunc( self, *a, **k ):
self.lock.acquire()
func( *a, **k )
self.lock.release()
4. List-only solution:
Use a dictionary, map item to its index.
To retrieve, sort on value, not key
'''
--
http://mail.python.org/mailman/listinfo/python-list
