42线程4_Semaphore_GIL

目录

threading.Semaphore类：... 1

数据结构Queue：... 5

GIL. 5

threading.Semaphore类：

线程同步技术；

和Lock很像，信号量内部维护一个倒计数器，每一次acquire都会减1（release加1），当acquire方法发现计数为0就阻塞，直至其它线程对信号量release后，计数大于0，恢复阻塞的线程；

倒计数器永远不会<0，是非负数，因为acquire时发现是0都会被阻塞；

与linux OS的信号完全不同；

s=threading.Semaphore(value=1)，构造方法，value<0抛ValueError异常；

s.acquire(blocking=True,timeout=None)，获取信号量，计数器减1，获取成功返回True；

s.release()，释放信号量，计数器加1；

应用场景：

连接池；

因为资源有限，每开启一个，连接成本很高（TCP三次握手四次挥手等），所以使用连接池；

threading.BoundedSemaphore类：

有界的信号量，作上界控制；

不允许使用release超出初始值的范围，否则抛ValueError异常；

信号量和锁：

锁，只允许同一个时间一个线程独占资源，它是特殊的信号量，即信号量计数器初值为1；

信号量，允许多个线程访问共享资源，但这个共享资源数量有限；

锁，可看作是特殊的信号量；

例：

def work(s:threading.Semaphore):

    logging.info('in sub')

    s.acquire()

    logging.info('end sub')

s = threading.Semaphore(3)

logging.info(s.acquire())

logging.info(s.acquire())

logging.info(s.acquire())

threading.Thread(target=work, args=(s,)).start()

print('~'*20)

time.sleep(2)

logging.info(s.acquire(False))

logging.info(s.acquire(timeout=3))

s.release()

print('end main')

输出：

2018-08-07-10:07:23       Thread info: 9360 MainThread True

2018-08-07-10:07:23       Thread info: 9360 MainThread True

2018-08-07-10:07:23       Thread info: 9360 MainThread True

2018-08-07-10:07:23       Thread info: 13180 Thread-1 in sub

~~~~~~~~~~~~~~~~~~~~

2018-08-07-10:07:25       Thread info: 9360 MainThread False

2018-08-07-10:07:28       Thread info: 9360 MainThread False

2018-08-07-10:07:28       Thread info: 13180 Thread-1 end sub

end main

例：

s = threading.Semaphore(3)

s.release()   #直接使用release改变了初始预设值

s.release()

s.release()

print(s.__dict__)

输出：

{'_value': 6, '_cond': <Condition(<unlocked _thread.lock object at 0x00000000012AB5D0>, 0)>}

例，解决超出预设值：

s = threading.BoundedSemaphore(3)

s.release()

输出：

Traceback (most recent call last):

  File "E:/git_practice/cmdb/example_threading2.py", line 359, in <module>

    s.release()

  File "D:\Python\Python35\lib\threading.py", line 480, in release

    raise ValueError("Semaphore released too many times")

ValueError: Semaphore released too many times

例：

连接池应有容量（总数），有一个工厂方法可获取连接，能够把不用的连接返回，供其它调用者使用；

class Conn:

    def __init__(self, name):

        self.name = name

class Pool:

    def __init__(self, count):

        self.count = count

        # self.pool = []

        self.pool = [self._connect('conn-{}'.format(i)) for i in range(count)]

    def _connect(self, conn_name):

        return Conn(conn_name)

    def get_conn(self):   #此方法在多线程时有安全问题；如果池中正好有一个连接，有可能多个线程判断池的长度是>0的，当一个线程拿走了连接对象，其它线程再来pop就抛异常，解决：用Lock或Semaphore

        # return self.pool.pop()

        if len(self.pool) > 0:

            return self.pool.pop()

    def return_conn(self, conn:Conn):

        self.pool.append(conn)

例，连接池改进：

class Conn:

    def __init__(self, name):

        self.name = name

class Pool:

    def __init__(self, count):

        self.count = count

        self.pool = [self._connect('conn-{}'.format(i)) for i in range(count)]

        # self.sema = threading.Semaphore(count)

        self.sema = threading.BoundedSemaphore(count)   #信号量比计算列表长度要好

    def _connect(self, conn_name):

        return Conn(conn_name)

    def get_conn(self):

        self.sema.acquire()

        data = self.pool.pop()

        return data

    def return_conn(self, conn:Conn):

        self.pool.append(conn)

        self.sema.release()

pool = Pool(3)

def work(pool:Pool):

    conn = pool.get_conn()

    logging.info(conn)

    threading.Event().wait(random.randint(1,4))

    pool.return_conn(conn)

for i in range(6):

    threading.Thread(target=work, args=(pool,), name='worker-{}'.format(i)).start()

输出：

2018-08-07-14:09:11       Thread info: 3264 worker-0 <__main__.Conn object at 0x00000000014E6780>

2018-08-07-14:09:11       Thread info: 12452 worker-1 <__main__.Conn object at 0x00000000014E6630>

2018-08-07-14:09:11       Thread info: 11468 worker-2 <__main__.Conn object at 0x00000000014E6748>

2018-08-07-14:09:13       Thread info: 13228 worker-3 <__main__.Conn object at 0x00000000014E6748>

2018-08-07-14:09:14       Thread info: 12692 worker-4 <__main__.Conn object at 0x00000000014E6780>

2018-08-07-14:09:15       Thread info: 6748 worker-5 <__main__.Conn object at 0x00000000014E6630>

注：

使用信号量解决资源有限问题；

如果池中有资源，请求者获取资源时信号量减1，拿走资源；

当请求超过资源数，请求者只能等待；

当使用者用完归还资源后信号量加1，等到线程拿到就可唤醒拿走资源；

以上，从程序逻辑上分析：

1、如果还没有使用信号量就release，会怎么样？

超出预设值，解决用threading.BoundedSemaphore；

2、如果使用了信号量，但还没用完？

        self.pool.append(conn)

        self.sema.release()

如果一种极端情况，计数器还差1个就满了，有三个线程A、B、C都执行了第一句，都没来得及release，这时轮到线程A release，然后轮到C release，这时一定出问题，超界了ValueError，因此有界信号量能保证，一定不能多归还；

3、很多线程用完了信号量？

没有获得信号量的线程都阻塞，没有线程和归还的线程争抢，当append后才release，这时才能等待的线程被唤醒，才能pop，即没有获取信号量就不能pop，这是安全的；

数据结构Queue：

标准库；

提供FIFO和LIFO的Queue，优先队列；

Queue类是线程安全的，适用于多线程间安全的交换数据，内部使用了Lock和Condition；

魔术方法中，说实现容器的大小不准确？

如果不加锁，是不可能获得准确的大小的，因为当前线程刚读取了一个大小，还没取走，就有可能被其它线程改掉了；

Queue类的size虽加了锁，但依然不能保证立即get、put就能成功，因为读取大小和get、put方法是分开的；

GIL

gobal intepreter lock，全局解释器锁；

GIL保证cpyton进程中，只有一个线程执行字节码，甚至在多核cpu情况下也是如此；ruby中也有GIL；另，其它解释器没有这种情况，如pypy、jython等；

cpython中没有真正的多线程；

GIL的本质：理解cpython多线程；

cpython中：

IO密集型，由于线程阻塞，就会调度其它线程；

cpu密集型，当前线程可能会连续的获得GIL，导致其它线程几乎无法使用cpu；

IO密集型，使用多线程；

cpu密集型，使用多进程，绕开GIL；

新版cpython正努力优化GIL问题，但不是移除；

如果非要使用多线程且要有效率，请绕行，选择其它语言go、erlang等；

py中绝大多数内置数据结构都是原子操作，如lst.append()、lst.pop()；

由于GIL的存在，py的内置数据类型在多线程编程时就变为安全的了，但实际上它们本身不是线程安全的；

项目一开始就要固定使用某一解释器的XX版本；

保留GIL的原因：

guido坚持的简单哲学，对于初学者门槛低，不需要高深的系统知识也能安全、简单的使用py；

若移除GIL，会降低cpython单线程的执行效率；

例1：

def calc():

    sum = 0

    for _ in range(100000000):

        sum += 1

start = datetime.datetime.now()

calc()

calc()

calc()

calc()

calc()

delta = (datetime.datetime.now() - start).total_seconds()

print(delta)

输出：

32.942885

例2：

def calc():

    sum = 0

    for _ in range(100000000):

        sum += 1

start = datetime.datetime.now()

lst = []

for _ in range(5):   #CPU密集型，用多进程解决

    t = threading.Thread(target=calc)

    t.start()

    # t.join()   #t.join()不能放在此处，若放在此处是串行（第1个线程执行完才能循环执行到下一个线程），不是并行

    lst.append(t)

for t in lst:

    t.join()

delta = (datetime.datetime.now() - start).total_seconds()

print(delta)

输出：

32.487859

对比例1和例2：

从结果上看，单线程和多线程一样，cpython的多线程没有优势和一个线程执行时间相当，因为GIL的存在；