[Metakit] thread safe in python

[Eric S. Johansson]

William K. Volkman wrote:
> On Mon, 2005-05-09 at 07:41, Brian Kelley wrote:
> 
>> My python metakit server shares a storage object between threads.
>> In fact, you have to do this if you are modifying contents between 
>> threads.
>> 
>> I have also used this successfully in a webware threaded web server
>>  with no adverse effects.

> It is probably worth noting that since the Global Interpreter Lock is
> not released by the Metakit interface module this means that no other
> python threads will run pending the completion of the call.  This is
> not so much thread-safe as thread-protected or serialized.  The net
> effect, if your tasks are mostly I/O oriented, is that threading buys
> you nothing.

sort of true.  when you're executing python and threading is turned on, 
you are using native threads.  You get context switches as often as that 
environment allows.  Yes, when you are in an extension, threading stops. 
  And if what I read on the net is true, this is a good thing.

However, it's possible for a context switch to happen between view 
operations which is part of the reason why I was asking about locking 
requirements a multithreaded context.  I'm probably answering my own 
question which is that I need to lock on logical access (i.e. search 
then write) in order to prevent confusion.  Unless of course I have a 
single view per thread and there is no problem was simultaneous access 
read or write.

---eric


-- 
http://www.wired.com/wired/archive/13.03/view.html?pg=5

The result of the duopoly that currently defines "competition" is that
prices and service suck. We're the world's leader in Internet
technology - except that we're not.