semaphore

在多线程的编程环境中，锁的使用必不可少！ 于是，今天来总结一下为共享资源加锁的操作方法。 一、使用 synchronized 方式 // 线程 1 dispatch_async ( dispatch_get_global_queue ( DISPATCH_QUEUE_PRIORITY_DEFAULT , 0 ), ^{ @synchronized ( _myLockObj ){ [obj1 method1 ]; sleep ( 30 ); } @synchronized (obj1){ } }); // 线程 2 dispatch_async ( dispatch_get_global_queue ( DISPATCH_QUEUE_PRIORITY_DEFAULT , 0 ), ^{ sleep ( 1 ); @synchronized ( _myLockObj ){ [obj1 method2 ]; } }); } 这样，就会起到锁的作用，线程2会等待线程1执行完成 @synchronized (obj){ }块后，在执行。从而起到锁的作用。 2.使用 NSLock 方式 先贴一个例子： 1. TestObj.h @interface TestObj : NSObject - ( void )method1; - ( void )method2; @end 2. TestObj

一、Semaphore用法 Semaphore ['seməfɔː] 信号 Semaphore翻译成字面意思为 信号量，Semaphore可以控同时访问的线程个数，通过 acquire() 获取一个许可，如果没有就等待，而 release() 释放一个许可。 二、Semaphore 方法讲解 Semaphore类位于java.util.concurrent包下，它提供了2个构造器： //参数permits表示许可数目，即同时可以允许多少线程进行访问 public Semaphore(int permits) { sync = new NonfairSync(permits); } //这个多了一个参数fair表示是否是公平的，即等待时间越久的越先获取许可 public Semaphore(int permits, boolean fair) { sync = (fair)? new FairSync(permits) : new NonfairSync(permits); } 下面说一下Semaphore类中比较重要的几个方法，首先是acquire()、release()方法： public void acquire() throws InterruptedException { } //获取一个许可 public void acquire(int permits) throws

Gevent官网文档地址： http://www.gevent.org/contents.html 进程、线程、协程区分 我们通常所说的协程Coroutine其实是corporate routine的缩写，直接翻译为协同的例程，一般我们都简称为协程。 在linux系统中，线程就是轻量级的进程，而我们通常也把协程称为轻量级的线程即微线程。 进程和协程 下面对比一下进程和协程的相同点和不同点： 相同点： 相同点存在于，当我们挂起一个执行流的时，我们要保存的东西： 栈， 其实在你切换前你的局部变量，以及要函数的调用都需要保存，否则都无法恢复 寄存器状态,这个其实用于当你的执行流恢复后要做什么 而寄存器和栈的结合就可以理解为上下文，上下文切换的理解： CPU看上去像是在并发的执行多个进程，这是通过处理器在进程之间切换来实现的，操作系统实现这种交错执行的机制称为上下文切换 操作系统保持跟踪进程运行所需的所有状态信息。这种状态，就是上下文。 在任何一个时刻，操作系统都只能执行一个进程代码，当操作系统决定把控制权从当前进程转移到某个新进程时，就会进行上下文切换，即保存当前进程的上下文，恢复新进程的上下文，然后将控制权传递到新进程，新进程就会从它上次停止的地方开始。 不同点： 执行流的调度者不同，进程是内核调度，而协程是在用户态调度，也就是说进程的上下文是在内核态保存恢复的

一、乐观锁 　　乐观锁是一种乐观思想，即认为读多写少，遇到并发写的可能性低，每次去拿数据时都认为别人不会修改，所以不会上锁，但是在更新时会判断一下在此期间别人有没有去更新这个数据，采取在写时先读出当前版本号，然后加锁操作（比较跟上一次的版本号，如果一样则更新），如果失败则要重复读-比较-写操作。 　　Java中的乐观锁基本是通过CAS操作实现的，CAS是一种更新的原子操作，比较当前值跟传入值是否一样，一样则更新，否则失败。 二、悲观锁 　　悲观锁就是悲观思想，即认为写多，遇到并发写的可能性高，每次去拿数据时都认为被人会修改，所以每次在读写数据时都会上锁。这样别人想读写这个数据就会block知道拿到锁。Java中的悲观所就是Synchronized，AQS框架下的锁则是先尝试CAS乐观锁去获取锁，若获取不到时，才会转换为悲观锁，如RetreenLock。 三、Synchronized同步锁 可以把任意一个非null的对象当作锁，它属于独占式的悲观锁，同时属于可重入锁。 作用范围： 　　1）作用于方法时，锁住的是对象的实例（this）； 　　2）作用于静态方法时，锁住的是Class实例，又因为Class的相关数据存储在永久代PermGen（JDK1.8则是metaspace），永久代是全局共享的，因此静态方法相当于类的一个全局锁，会锁所有调用该方法的线程。 　　3

I am trying to port a project (from linux) that uses Semaphores to Mac OS X however some of the posix semaphores are not implemented on Mac OS X The one that I hit in this port is sem_timedwait() I don't know much about semaphores but from the man pages sem_wait() seems to be close to sem_timedwait and it is implemented From the man pages sem_timedwait() function shall lock the semaphore referenced by sem as in the sem_wait() function. However, if the semaphore cannot be locked without waiting for another process or thread to unlock the semaphore by performing a sem_post() function, this wait

In a graduate class, we've had to use semaphores to accomplish work with threads. We were directed to use sem_init along with a bunch of other sem_* procedure but we were not given much information about the details of each of these sem_* methods. The prototype (and header file) of sem_init is the following : #include <semaphore.h> int sem_init(sem_t *sem, int pshared, unsigned int value); but I don't understand what the pshared value is used for. According to opengroup.org : If the pshared argument has a non-zero value, then the semaphore is shared between processes; in this case, any process

[20191119]探究ipcs命令输出2.txt --//继续上午的测试:http://blog.itpub.net/267265/viewspace-2664758/=>[20191119]探究ipcs命令输出.txt --//先补充ipcs 剩余2个参数 -l -u --//-l limits --//-u summary $ ipcs -l ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 67108864 max total shared memory (kbytes) = 17179869184 min seg size (bytes) = 1 ------ Semaphore Limits -------- max number of arrays = 128 max semaphores per array = 2600 max semaphores system wide = 332800 max ops per semop call = 2600 semaphore max value = 32767 ------ Messages: Limits -------- max queues system wide = 32768

I'm a little confused by the Linux API sem_unlink(), mainly when or why to call it. I've used semaphores in Windows for many years. In Windows once you close the last handle of a named semaphore the system removes the underlying kernel object. But it appears in Linux you, the developer, needs to remove the kernel object by calling sem_unlink(). If you don't the kernel object persists in the /dev/shm folder. The problem I'm running into, if process A calls sem_unlink() while process B has the semaphore locked, it immediately destroys the semaphore and now process B is no longer "protected" by

There are two queues of children waiting to use a roundabout in a playground – one is facing it from the north, one from the south. Children may only enter the roundabout from the front of either queue and may only enter if there is a space available (only one child may use each segment at a time). Once on the roundabout they use it for a random period of time, then leave, either to the east or west, at random. They then play elsewhere for a random period and, after that, re-enter a north/south queue at random, and so on ad infinitum. The roundabout rotates clockwise and a queuing child will