$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Achilleas Margaritis (axilmar_at_[hidden])
Date: 2007-12-02 14:59:01
O/H Peter Dimov ÎγÏαÏε:
> Achilleas Margaritis:
>
>> Isn't there a deadlock issue with futures? suppose I have the following
>> code:
>>
>> class A {
>> int data;
>>
>> public:
>> int getData() const {
>> return data;
>> }
>>
>> void someAction(B *b) {
>> future<int> i = bind(b, &B::someAction, this);
>> data = i.wait() + 1;
>> }
>> };
>>
>> class B {
>> int data;
>>
>> public:
>> int someAction(A *a) {
>> future<int> j = bind(a, &A::getData);
>> return j.wait() + 1;
>> }
>> };
>>
>> int main() {
>> A *a = new A;
>> B *b = new B;
>> a->someAction(b);
>> }
>>
>> The above contains a deadlock:
>
> It doesn't, unless the future<int> contains a magic per-object mutex. It
> would be a deadlock if A is changed as follows:
>
> class A {
> int data;
> mutable mutex mx;
>
> public:
> int getData() const {
> scoped_lock lock( mx );
> return data;
> }
>
> void someAction(B *b) {
> scoped_lock lock( mx );
> future<int> i = bind(b, &B::someAction, this);
> data = i.wait() + 1;
> }
> };
>
> which is broken. A mutex lock should never encompass a blocking call.
>
> class A {
> int data;
> mutable mutex mx;
>
> public:
> int getData() const {
> scoped_lock lock( mx );
> return data;
> }
>
> void setData( int v )
> {
> scoped_lock lock( mx );
> data = v;
> }
>
> void someAction(B *b) {
> future<int> i = bind(b, &B::someAction, this);
> setData( i.wait() + 1 );
> }
> };
>
> _______________________________________________
> Unsubscribe & other changes: http://listarchives.boost.org/mailman/listinfo.cgi/boost
>
Aaaah yes, it's because each future is a different thread.
But it would be a deadlock in the Actor model, where B's thread would
wait A's thread and A's thread would wait for B's thread.