6

OK the code is pretty basic. Since I'm using multiple threads, and I want shared variables between them, I'm using a global.

Why does the code in ThreadClass sometimes not execute when I hit "C"? I know it's a concurrency problem, but I'm not sure how to fix it. I've reading up on semaphores and locking lately, but I'm not exactly sure how to implement it at the moment. Any suggestions are welcome. 

import threading
buff_list = []

class ThreadClass(threading.Thread):
    global buff_list
    def run(self):
        while (True):
            if ("C" == raw_input()):
                buff_list.append("C")
                print buff_list

class ThreadClass2(threading.Thread):
    global buff_list
    def run(self):
        while(True):
            if ("B" == raw_input() and len(buff_list) > 0):
                buff_list.pop()
                print buff_list

a = ThreadClass()
b = ThreadClass2()

a.start()
b.start()
Improve this question
2
  • 3
    Two side notes: In Python you don't need parentheses around while and if conditions, and shouldn't use them. Also, you never need to check len(buff_list) > 0; just check buff_list, because any sequence is truthy iff it's not empty. The problem with adding unnecessary parentheses, len checks, etc. is that most Python programmers will assume you were trying to do something for which they are necessary, and waste time and mental effort trying to guess what your intention was. Commented Jun 3, 2013 at 21:23
  • Also, you usually don't want to call list.pop() and not store the result anywhere. But I assume you know that, and were just doing it this way because it's a toy example (the value can't be anything but "C", and you have nothing useful to do with it anyway). Commented Jun 3, 2013 at 21:24

3 Answers 3

Reset to default
6

You have two synchronization problems here.

Let's deal with the easier one first, the fact that you're sharing a global buff_list that the two threads fight over. There's nothing stopping one thread from trying to append at the same time the other thread pops, which is illegal. And, even if you get lucky and that doesn't happen, the pop could come before the append.

The simplest way to solve this is to use a Queue, which is automatically-synchronizing:

buff_list = Queue.Queue()

Then just use put instead of append, and get instead of pop.

However, if you want to learn how to this stuff yourself, there are two possible ways to go.

First, you can use a Lock. (You can also use an RLock, but let's forget that for now.) This makes sure that only one thread is accessing buff_list at a time.

buff_lock = threading.Lock()
buff_list = []

Now, whenever you append or pop, just grab the lock:

with buff_lock:
    buff_list.append("C")

with buff_lock:
    val = buff_list.pop()

But this won't make sure the popping code waits until there's something to pop. If you want to do that, use a Condition:

buff_cond = threading.Condition()

Now:

with buff_cond:
    buff_list.append("C")
    buff_cond.notify()

with buff_cond:
    while not buff_list:
        buff_cond.wait()
    value = buff_list.pop()

The second problem is that you're implicitly sharing sys.stdin, because both threads are calling raw_input. Unless you have some way to synchronize things so that each thread knows when it's supposed to get the next input (and that may be hard to even describe, and you can't turn it into code if you can't describe it), that can't possibly work—every time you type C there's a 50/50 chance that the wrong thread will get it.

So, as kirelagin suggests, you need to make exactly one thread responsible for the I/O. The easiest way to do this is again to use a Queue, and have one thread put any inputs it doesn't use, and the other thread can get from the queue.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

The simplest way to solve this is to avoid using threads where you don't need theads…
@kirelagin: Well, yes, in the same way that the simplest way to solve any coding problem is to not write any code…
well @kirelagin I'm trying to make a bigger threading program later on. So to do so, I wanted to first understand how it works in a really basic program.
Taking the original code and rewriting it to use locks per @abamert's comments was a great exercise for me. Thanks.
4

Well you never know instance of which class got your input. If you hit “C” and that was ThreadClass2 reading your input, it will just do nothing since "B" == raw_input() will be False.

Exactly one thread should be responsible for I/O.

Improve this answer

Comments

0

In addition to what is said in the previous replies, i would like to add that threading module also supports more primitive mechanisms implemented also in all other languages, such as the Semaphore Objects.

This is one of the oldest synchronization primitives in the history of computer science, invented by the early Dutch computer scientist Edsger W. Dijkstra (he used P() and V() instead of acquire() and release()).

The best way to learn threading in deep is starting from scratch, i think.

Improve this answer

3 Comments

I think it's a lot easier to start with Queue, then figure out how to write Queue yourself on top of Lock and Condition, then figure out how to write Lock and Condition on top of Semaphore and Event (writing Condition that way is hard, and the result will not be very efficient), rather than starting with the lowest-level primitives and trying to figure out what you could conceivably build out of them.
Easy is often in contradiction with best. You will not have Queue or Event at kernel level for example. Use them at the beginning force lazy programming. If you want to learn in depth the concept of thread synchronization and let it works in every context and language, then the road is a bit harder but it brings greater results. This is what I meant. However, there may be different ways depending on the purposes. I only suggested a possibility :)
Yes, it's important to know how to write a condition or a synchronized queue or a lock-free list out of nothing but semaphores, events, and compare-and-exchange. But until you know what they're used for, you can't do that. Instead, you'll build useless things at the wrong level of abstraction that work 99.99% of the time, and spend 99.99% of your time debugging code that doesn't even make sense. It took the industry a couple of decades to figure out the useful abstractions, and if you try to work bottom-up and discover the abstractions yourself, it will take you just as long.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.