Compiler gives wrong output

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Compiler gives wrong output

U.Mutlu
Hi,
on this page:
http://en.cppreference.com/w/cpp/thread/recursive_mutex/try_lock
they give the following C++11 example:

#include <iostream>
#include <mutex>

int main()
{
     std::mutex test;
     if (test.try_lock()==true) {
         std::cout << "lock acquired" << std::endl;
         test.unlock();    //now unlock the mutex
     } else {
         std::cout << "lock not acquired" << std::endl;
     }

     test.lock();    //to lock it again
     if (test.try_lock()) {  //true can be left out
         std::cout << "lock acquired" << std::endl;
     } else {
         std::cout << "lock not acquired" << std::endl;
     }
     test.unlock();
}

and they say it would give this output:
Output:
lock acquired
lock not acquired

I wonder why my compiler (g++ 4.9.2 from Debian repo) gives a different output:
lock acquired
lock acquired

Which compiler is wrong, and why?

Besides that: doesn't the code contain the wrong mutex:
shouldn't it rather be "std::recursive_mutex" for a recursive mutex?

Thx

My compile switches:

$ g++ -Wall -O2 -std=c++11 t.cpp
$ ./a.out
lock acquired
lock acquired

$ g++ -Wall -O2 -std=gnu++11 t.cpp
$ ./a.out
lock acquired
lock acquired



_______________________________________________
help-gplusplus mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-gplusplus
Reply | Threaded
Open this post in threaded view
|

Re: Compiler gives wrong output

Richard Kettlewell
"U.Mutlu" <[hidden email]> writes:

> Hi,
> on this page:
> http://en.cppreference.com/w/cpp/thread/recursive_mutex/try_lock
> they give the following C++11 example:
>
> #include <iostream>
> #include <mutex>
>
> int main()
> {
>     std::mutex test;
>     if (test.try_lock()==true) {
>         std::cout << "lock acquired" << std::endl;
>         test.unlock();    //now unlock the mutex
>     } else {
>         std::cout << "lock not acquired" << std::endl;
>     }
>
>     test.lock();    //to lock it again
>     if (test.try_lock()) {  //true can be left out
>         std::cout << "lock acquired" << std::endl;
>     } else {
>         std::cout << "lock not acquired" << std::endl;
>     }
>     test.unlock();
> }
>
> and they say it would give this output:
> Output:
> lock acquired
> lock not acquired
>
> I wonder why my compiler (g++ 4.9.2 from Debian repo) gives a different output:
> lock acquired
> lock acquired
>
> Which compiler is wrong, and why?

AIUI, neither is wrong.  The code violates the preconditions of
try_lock(), and therefore results in undefined behavior.

--
http://www.greenend.org.uk/rjk/
_______________________________________________
help-gplusplus mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-gplusplus
Reply | Threaded
Open this post in threaded view
|

Re: Compiler gives wrong output

U.Mutlu
Richard Kettlewell wrote on 06/09/2015 10:16 AM:

> "U.Mutlu" <[hidden email]> writes:
>> Hi,
>> on this page:
>> http://en.cppreference.com/w/cpp/thread/recursive_mutex/try_lock
>> they give the following C++11 example:
>>
>> #include <iostream>
>> #include <mutex>
>>
>> int main()
>> {
>>      std::mutex test;
>>      if (test.try_lock()==true) {
>>          std::cout << "lock acquired" << std::endl;
>>          test.unlock();    //now unlock the mutex
>>      } else {
>>          std::cout << "lock not acquired" << std::endl;
>>      }
>>
>>      test.lock();    //to lock it again
>>      if (test.try_lock()) {  //true can be left out
>>          std::cout << "lock acquired" << std::endl;
>>      } else {
>>          std::cout << "lock not acquired" << std::endl;
>>      }
>>      test.unlock();
>> }
>>
>> and they say it would give this output:
>> Output:
>> lock acquired
>> lock not acquired
>>
>> I wonder why my compiler (g++ 4.9.2 from Debian repo) gives a different output:
>> lock acquired
>> lock acquired
>>
>> Which compiler is wrong, and why?
>
> AIUI, neither is wrong.  The code violates the preconditions of
> try_lock(), and therefore results in undefined behavior.

Mystery solved: when using such concurrency/thread objects,
then one has to link with pthread (-lpthread):
  g++ -Wall -O2 -std=gnu++11 file.cpp -lpthread
Now my compiler gives the same result.




_______________________________________________
help-gplusplus mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-gplusplus