Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Do I need a lock here?

Reply
Thread Tools

Do I need a lock here?

 
 
jasiu85
Guest
Posts: n/a
 
      10-27-2008
Hey,

Please take a look at the code of the two threads below:

COMMON_DICT = {}

def thread_1():
global COMMON_DICT
local_dict = prepare_dict()
COMMON_DICT = local_dict

def thread_2():
global COMMON_DICT
local_dict = COMMON_DICT
use_dict(local_dict)

Do I need a lock to protect the COMMON_DICT dictionary? AFAIK bytecode
operations are atomic and in each thread there's only one crucial
bytecode op: STORE_NAME in the first thread and LOAD_NAME in the
second one. So I suspect that everything will work just fine. Am I
right?

Regards,

Mike
 
Reply With Quote
 
 
 
 
Diez B. Roggisch
Guest
Posts: n/a
 
      10-27-2008
jasiu85 schrieb:
> Hey,
>
> Please take a look at the code of the two threads below:
>
> COMMON_DICT = {}
>
> def thread_1():
> global COMMON_DICT
> local_dict = prepare_dict()
> COMMON_DICT = local_dict
>
> def thread_2():
> global COMMON_DICT
> local_dict = COMMON_DICT
> use_dict(local_dict)
>
> Do I need a lock to protect the COMMON_DICT dictionary? AFAIK bytecode
> operations are atomic and in each thread there's only one crucial
> bytecode op: STORE_NAME in the first thread and LOAD_NAME in the
> second one. So I suspect that everything will work just fine. Am I
> right?


Depending on what you mean by "right".

The above is not enough to judge what is really happening. But depending
on the execution order, thread_1 overwrites the reference in COMMON_DICT
*after* thread_2 has altered it.

But it won't crash or anything. If that's right for you.

Diez
 
Reply With Quote
 
 
 
 
jasiu85
Guest
Posts: n/a
 
      10-28-2008
On Oct 27, 10:12*am, "Diez B. Roggisch" <(E-Mail Removed)> wrote:
> jasiu85 schrieb:
>
>
>
> > Hey,

>
> > Please take a look at the code of the two threads below:

>
> > COMMON_DICT = {}

>
> > def thread_1():
> > * * global COMMON_DICT
> > * * local_dict = prepare_dict()
> > * * COMMON_DICT = local_dict

>
> > def thread_2():
> > * * global COMMON_DICT
> > * * local_dict = COMMON_DICT
> > * * use_dict(local_dict)

>
> > Do I need a lock to protect the COMMON_DICT dictionary? AFAIK bytecode
> > operations are atomic and in each thread there's only one crucial
> > bytecode op: STORE_NAME in the first thread and LOAD_NAME in the
> > second one. So I suspect that everything will work just fine. Am I
> > right?

>
> Depending on what you mean by "right".
>
> The above is not enough to judge what is really happening. But depending
> on the execution order, thread_1 overwrites the reference in COMMON_DICT
> *after* thread_2 has altered it.
>
> But it won't crash or anything. If that's right for you.
>
> Diez


The second thread doesn't alter the dictionary, it only reads it. Even
if the first thread puts a reference to a new dictionary into the
COMMON_DICT variable while the second thread is reading the old
dictionary, such sematics is fine for me. I'm seeking for a kind of
Producer/Consumer pattern. So the first thread produces some data in a
form of a dictionary. The second thread reads it from time to time.
It's sufficient for me if a dictionary is "lost" because the first
thread overwrites the COMMON_DICT variable before the second thread
tries to read it. It's also sufficient for me if the first thread
updates COMMON_DICT variable while the second thread is reading the
previous copy of the dictionary. So from my point of view the most
critical parts are these two lines:

COMMON_DICT = local_dict # in the first thread
local_dict = COMMON_DICT # in the second thread

Can these two instructions by any chance interfere with each other in
a way that will crash either of the threads?

I hope I made myself a little bit more clear .

Thanks!!

Mike
 
Reply With Quote
 
Aaron Brady
Guest
Posts: n/a
 
      10-28-2008
On Oct 28, 3:29*pm, jasiu85 <(E-Mail Removed)> wrote:
> On Oct 27, 10:12*am, "Diez B. Roggisch" <(E-Mail Removed)> wrote:
>
>
>
> > jasiu85 schrieb:

>
> > > Hey,

>
> > > Please take a look at the code of the two threads below:

>
> > > COMMON_DICT = {}

>
> > > def thread_1():
> > > * * global COMMON_DICT
> > > * * local_dict = prepare_dict()
> > > * * COMMON_DICT = local_dict

>
> > > def thread_2():
> > > * * global COMMON_DICT
> > > * * local_dict = COMMON_DICT
> > > * * use_dict(local_dict)

>
> > > Do I need a lock to protect the COMMON_DICT dictionary? AFAIK bytecode
> > > operations are atomic and in each thread there's only one crucial
> > > bytecode op: STORE_NAME in the first thread and LOAD_NAME in the
> > > second one. So I suspect that everything will work just fine. Am I
> > > right?

>
> > Depending on what you mean by "right".

>
> > The above is not enough to judge what is really happening. But depending
> > on the execution order, thread_1 overwrites the reference in COMMON_DICT
> > *after* thread_2 has altered it.

>
> > But it won't crash or anything. If that's right for you.

>
> > Diez

>
> The second thread doesn't alter the dictionary, it only reads it. Even
> if the first thread puts a reference to a new dictionary into the
> COMMON_DICT variable while the second thread is reading the old
> dictionary, such sematics is fine for me. I'm seeking for a kind of
> Producer/Consumer pattern. So the first thread produces some data in a
> form of a dictionary. The second thread reads it from time to time.
> It's sufficient for me if a dictionary is "lost" because the first
> thread overwrites the COMMON_DICT variable before the second thread
> tries to read it. It's also sufficient for me if the first thread
> updates COMMON_DICT variable while the second thread is reading the
> previous copy of the dictionary. So from my point of view the most
> critical parts are these two lines:
>
> COMMON_DICT = local_dict # in the first thread
> local_dict = COMMON_DICT # in the second thread
>
> Can these two instructions by any chance interfere with each other in
> a way that will crash either of the threads?
>
> I hope I made myself a little bit more clear .
>
> Thanks!!
>
> Mike


I vote for OK, in this /very/ /particular/ /case/, but what would you
accept as evidence?

These pointer values start out different and become the same, but both
are dictionaries.

10490912 10490912
10490912 10490912
10490912 10490624
10490912 10490624
10490624
10490624 10490624
10490624 10490624
10490624 10490624

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Read-Write Lock vs primitive Lock() k3xji Python 7 12-30-2008 10:19 PM
Application.Lock()/UnLock() or lock(Application) nano2k ASP .Net Web Services 2 08-09-2007 09:31 AM
In a datagrid need to lock the header Jennyfer J Barco ASP .Net 0 09-24-2004 04:39 PM
Threading - Why Not Lock Objects Rather than lock the interpreter Fuzzyman Python 3 12-05-2003 10:43 PM
RE: Threading - Why Not Lock Objects Rather than lock theinterpreter Robert Brewer Python 0 12-05-2003 05:33 PM



Advertisments