Mutex::lock will block all threads? about pthreads

[krakjoe]

<?php
/* wrap access to a value you want to use as static is one valid approach */
class myStaticVar extends Stackable {
    public function __construct($initial=0) {
        $this->value = $initial;
    }
    public function increment() {
        return ++$this->value;
    }
    public function decrement() {
        return --$this->value;
    }
    public function run(){}
}
/* why on earth are you creating 500 threads ?? */
class a extends Thread
{
    public function __construct($mutex, $static)
    {
        $this->shared = $mutex;
        $this->my = $static;
    }


    public function run()
    {
        Mutex::lock($this->shared);
        $this->my->increment();
        Mutex::unlock($this->shared);
    }
}
/* mutex::create(true) would give you a mutex locked by the thread or process that called create */
$shared = Mutex::create();
/* because this is stackable it will behave properly among threads, static variables will not and should be avoided */
$static = new myStaticVar();

/* again, 500 ?? */
$arr = array();
for ($i=0;$i<=500;$i++) {
    $arr[$i]=new a($shared, $static);
    $arr[$i]->start();
}
/* cleanup at least */
foreach($arr as $t)
    $t->join();
/* your value should now be 501 having started 500 threads to increment it's value */
printf("resulting static %d\n", $static->value);
?>

Above is a version of your code that will work. A few notes contained... sleep can behave strangely, don't use it, if you must sleep use usleep, or wait on a condition ( which is likely what you are doing anyway else why sleep, in the real world ).

Some additional things to think about, 500 threads is horrible, don't do it. You do not need to use mutex to edit properties, reading and writing properties is thread safe. Using a threaded object as a base for any object intended for the multi-threaded environment is a good idea, the object is much better suited. If you wish for a method to be exclusive - ie only one thread can call it at a time, then use the protected keyword on that method.

Static members are not properly thread safe, don't use them. This is one of the major bugs that keeps giving people trouble - there is no way to provide thread safe access because internally the variables do not have an object scope they have a class scope, they are not stored in the class entry but in executor globals. Avoid using static variables completely, at least for the mean time ... I don't think a good solution exists here, I will persevere for a few more versions but ultimately they are likely to be removed ...

With those things in mind ...

<?php
class myStaticVar extends Stackable {
    public function __construct($initial=0) {
        $this->value = $initial;
    }
    public function increment() {
        return ++$this->value;
    }
    public function decrement() {
        return --$this->value;
    }
    public function run(){}
}
class a extends Thread
{
    public function __construct($static){
        $this->my = $static;
    }

    public function run()
    {
        $this->my->increment();
    }
}
?>

The above would do exactly the same job, in the real world where increment actually has some work to do, you make the method protected if you want for only one thread to do that particular piece of work at a time.

You should find that you do not need to use the mutex and condition class, they are probably destined for removal in stable versions of pthreads on account of the huge differences in implementation currently in use. pthreads is tolerant of these variations but not enough of the posix api is exposed in userland that your code can be as tolerant. So where possible, avoid them entirely by using more leveraging the features of the API.

[krakjoe]

Also, remember mutex::destroy on handles you ::create else you will leak memory.

[smallslime]

Thanks author.
I got it.

The reason i create 500 threads is, i wan't to write a multi threads pool with php, instead of php-fpm. Then, i could init framework, init config, init db pool, init memcached pool etc...and another bgthread do maintain and update

:)

[krakjoe]

See in the examples folder the pooling example, unless you have monster hardware, 500 threads makes no sense. You will get better throughput from less threads doing more work, for sure.