I just get stuck in this code, I assumed that the code locks the global variable "a" for 30 seconds but the output doesn't satisfy this assumption. Could any one help me figure out why this happens and another question is that is there any function to lock required variable for a specific time, being specified by the programmer. Thank you in advanced for your consideration.
#include <iostream>
#include <ctime>
#include <pthread.h>
#include <time.h>
#include <chrono>
using namespace std;
// std::chrono::seconds interval(100);
timed_mutex test_mutex;
int a = 0;
void * write(void * args)
{
auto start=std::chrono::steady_clock::now();
test_mutex.try_lock_until(start+std::chrono::seconds(30));
a = 2;
cout << "Here is place #" << a << endl;
test_mutex.unlock();
pthread_exit(NULL);
}
int main()
{
auto start=std::chrono::steady_clock::now();
pthread_t check;
pthread_create(&check, NULL, &write, NULL);
test_mutex.try_lock_until(start+std::chrono::seconds(30));
a = 1;
cout << "Here is place #" << a << endl;
test_mutex.unlock();
pthread_join(check, NULL);
return 0;
}
std::timed_mutex::try_lock_until returns either:
true when the mutex is acquired, or
false if it timed out (waited as long as allowed) trying to lock the mutex
Note that this code is buggy anyway, because it doesn't check the return value. So, a can be written even if the mutex was not acquired.
Related
I am trying to wrap my head around std::async and std::futures introduced in C++11.
#include <iostream>
#include <list>
#include <functional>
#include <vector>
#include <algorithm>
#include <thread>
#include <unistd.h>
#include <string>
#include <future>
using namespace std;
int hog_cpu()
{
cout << "hog_cpu" << endl;
volatile unsigned long long i = 0;
for(i = 0; i < 1000000000ULL ; i++);
return 50;
}
int hog_cpu_ex()
{
cout << "hog_cpu_ex" << endl;
volatile unsigned long long i = 0;
for(i = 0; i < 1000000000ULL ; i++);
return 500;
}
int main()
{
cout << "start threads asynchronously" << endl;
std::future<int> f1 = std::async(std::launch::async, hog_cpu);
std::future<int> f2 = std::async(std::launch::async, hog_cpu_ex);
cout << "Get the Results" << endl;
int r1 = f1.get();
int r2 = f2.get();
cout << "result 1: " << r1 << endl;
cout << "result 2: " << r2 << endl;
return 0;
}
The output of the above program that I get is shown below.
start threads asynchronously
Get the Results
hog_cpu_ex
hog_cpu
result 1: 50
result 2: 500
Process finished with exit code 0
My question is since I use std::launch::async the execution should start immideately using another thread. Where as the output tells me that it prints the line Get the results and then only the execution starts. (As evident from the logs above). Also hog_cpu_ex starts before hog_cpu. Can someone explain why this might be happening.
When you do
std::future<int> f1 = std::async(std::launch::async, hog_cpu);
std::future<int> f2 = std::async(std::launch::async, hog_cpu_ex);
You spin up two more threads of execution. Then the main thread keeps going after it calls each line and won't stop until it hits
int r1 = f1.get();
if f1 hasn't finished yet. Since the main thread keeps going and spinning up a thread takes some time it is pretty reasonable to see Get the Results print before the threads even start.
As for why do you see
hog_cpu_ex
hog_cpu
instead of the opposite is due to your operating system. It has control over which threads run and when so it is quite possible that it puts f1 to sleep, has space for f2 so it starts it running, and then starts f1 sometime after that.
I was experimenting with futures and promises and constructed a simple, although stupid example. In fact very stupid, but let's leave it.
I cannot understand why the following program doesn't wait for the input from user. It prints the slogan for the user to provide some number, but it doesn't wait. I know that similar problems were discussed here and on other forums and usually the answer was that the user forgot to join the thread. But I am joining the thread and even though this code doesn't work. What am I missing?
#include <iostream>
#include <chrono>
#include <future>
#include <memory>
using namespace std;
using namespace std::chrono_literals;
shared_ptr<promise<int>> prom;
auto fun()
{
prom = make_shared<promise<int>>();
auto ret = prom->get_future();
return ret;
}
int main(int argc, char* argv[])
{
thread t{ [] {
while(!prom){
cout << "Waiting for a promise" << endl;
std::this_thread::sleep_for(1s);
}
std::this_thread::sleep_for(1s);
cout << "OK, got the promise, now enter some value: " << endl;
int val;
cin >> val;
prom->set_value(val);
}};
std::this_thread::sleep_for(2s);
auto fut = fun();
t.join();
int v = fut.get();
cout << "You entered: " << v << endl;
}
Working example:
https://wandbox.org/permlink/AzTQer4rNkJcMBC7
I am running an asynchronous task and want to cancel it when a certain condition (bool) is met.
void MyClass::createTask()
{
this->future = std::async(std::launch::async, [this](){
while(this->CONDITION == false)
{
// do work
}
});
}
void MyClass::cancelTask()
{
this->CONDITION = true;
this->future.get();
}
Obviously, calling MyClass::cancelTask() would cause a data-race, because this->CONDITION is being written to and read from at the same time. So the first thing that came to my mind is to use a std::mutex. However that would mean that the task has to lock and unlock the mutex on every new iteration of the while-loop. Since the async task is performance critical, this seems like a bad choice.
Is there a cleaner, and especially a more perfomant way to achieve what I am trying to do? Switching from std::async to std::thread would be ok if it enabled an efficient solution.
As far as I know there is no elegant way to close a thread/async task in C++.
A simple way is to use std::atomic<bool> or std::atomic_flag instead of a mutex.
If you are familiar with boost library, than you could use boost::thread with interruption_points.
I have a solution for this kind of requeirements. I use std::mutex, std::condition_variable and std::unique_lock<std::mutex> to create tow methods: pauseThread and resumeThread.
The idea is use the condition_variable and unique_lock to make the thread wait for a time, for example 5 seconds, and after the time os over the thread continue its execution. But, if you want to interrupt the condition_variable you could use its method notify_one().
Using your code, and continue with your idea, i made some changes to your class:
MODIFICATION: I modify the flag bKeepRunning.
MyClass.h
#include <mutex>
#include <chrono>
#include <future>
#include <atomic>
class MyClass
{
std::atomic<bool> bKeepRunning;
std::mutex mtx_t;
std::condition_variable cv_t;
std::future<void> _future;
public:
MyClass();
~MyClass();
void createTask();
void stopTask();
void pauseThread(int time);
void resumeThread();
}
MyClass.cpp
#include "MyClass.h"
#include <iostream>
using namespace std;
MyClass::MyClass()
{
bKeepRunning = false;
}
MyClass::~MyClass()
{
}
void MyClass::createTask()
{
bKeepRunning = true;
_future = std::async(std::launch::async, [this]() {
int counter = 0;
cout << "Thread running" << endl;
while (bKeepRunning)
{
counter++;
cout << "Asynchronous thread counter = [" << counter << "]" << endl;
this->pauseThread(5);//Wait for 5 seconds
}
cout << "Thread finished." << endl;
});
}
void MyClass::stopTask()
{
cout << "Stoping Thread." << endl;
bKeepRunning = false;
resumeThread();
}
void MyClass::pauseThread(int time)
{
std::unique_lock<std::mutex> lck_t(mtx_t);
cv_t.wait_for(lck_t, chrono::seconds(time));
}
void MyClass::resumeThread()
{
cout << "Resumming thread" << endl;
cv_t.notify_one();
}
I made a console sample to show how it works:
Main.cpp
#include <iostream>
#include <sstream>
#include <string>
#include "MyClass.h"
using namespace std;
int main(int argc, char* argv[])
{
MyClass app;
char line[80];
cout << "Press Enter to stop thread." << endl;
app.createTask();
cin.getline(line,80);
app.stopTask();
}
If you need some other period of time to pause your thread, you can try to change the interval and time of chrono::seconds(time) to, for example, chrono::milliseconds(time) that is using milliseconds.+
At the end, if you execute this sample, you could get an output like:
I am getting into threading in C++ and was going some testing and got this error.
Here is my code:
#include <iostream>
#include <thread>
#include <unordered_map>
#include <string>
#include <vector>
using namespace std;
static vector<string> thisVector;
void thread1() {
for (int i = 0; i < 400; i++){
thisVector.push_back(to_string(i));
}
cout << "Finished 1" << endl;
return;
}
void thread2() {
for (int i = 0; i < 400; i++){
thisVector.push_back(to_string(i));
}
cout << "Finished 2" << endl;
return;
}
int main(int argc, const char * argv[]) {
thread first(thread1);
thread second(thread2);
first.join();
second.join();
cout << "done threading" << endl;
cout << thisVector.size() << endl;
return 0;
}
The weird thing is, sometimes I get the correct output, so 800. Sometimes I get a number slightly lower than that for I don't know what reason??? And sometimes I get the following error:
malloc: *** error for object 0x100400028: pointer being freed was not allocated
Any help would be greatly appreciated!
Thanks
A std::vector is not thread safe. You have two execution threads modifying the same std::vector concurrently. Operations on a std::vector should, in this case, be protected by a mutex.
The result of this is undefined behavior. As you've observed, sometimes it might work, sometimes wrong results get produced but the program completes successfully, sometimes the program crashes. This is what "undefined behavior" means.
It is worth reading The C++ Programming Language, it covers subjects of interest like : threads, tasks, but also at higher conceptual level future/promise, packaged_task, async.
In your case, you don't only deal with concurrency. You have to deal with shared data of concurrent threads. The way you programmed it does not guarantee any order of execution. That is why you get those strange results.
The error message you mentioned is likely to be because of concurrent access to the shared vector and it says what is wrong: a pointer is being freed (delete), but was not allocated beforehand. You don't see the pointer, it's an internal member of vector.
Your solution is to use a mutex to make sure that whenever a data is pushed back into the vector it does not get interrupted by the other concurrent thread and finishes appropriately, so that the next push_back starts only when the previous one has finished.
You can use a global variable for mutex. Then you need to deal appropriately with locking/unlocking, i.e. you must say when to acquire a mutex (before push_back) and when to release it (after push_back). Since you use only one mutex this should be fairly simple and should work.
You can try something like this:
#include <iostream>
#include <thread>
#include <unordered_map>
#include <string>
#include <vector>
using namespace std;
static vector<string> thisVector;
//Global MUTEX
mutex mv;
//
void thread1() {
for (int i = 0; i < 400; i++){
//Lock before and unlock after push back
mv.lock();
thisVector.push_back(to_string(i));
mv.unlock();
}
cout << "Finished 1" << endl;
return;
}
void thread2() {
for (int i = 0; i < 400; i++){
mv.lock();
thisVector.push_back(to_string(i));
mv.unlock();
}
cout << "Finished 2" << endl;
return;
}
int main(int argc, const char * argv[]) {
thread first(thread1);
thread second(thread2);
first.join();
second.join();
cout << "done threading" << endl;
cout << thisVector.size() << endl;
return 0;
}
I think I must be assuming something from the name boost::interprocess that is not true.
The documents repeat that named_mutex is global here.
I am unable to make it work though. Two copies of the same executable should be run at the same time, and I expect that a named mutex in a library named boost::interprocess might actually BLOCK sometimes. It doesn't. It also doesn't prevent data file corruption in the code below.
Here's some code from the boost docs:
#include <boost/interprocess/sync/scoped_lock.hpp>
#include <boost/interprocess/sync/named_mutex.hpp>
#include <fstream>
#include <iostream>
#include <cstdio>
int main ()
{
using namespace boost::interprocess;
try{
struct file_remove
{
file_remove() { std::remove("file_name"); }
~file_remove(){ std::remove("file_name"); }
} file_remover;
struct mutex_remove
{
mutex_remove() { named_mutex::remove("fstream_named_mutex"); }
~mutex_remove(){ named_mutex::remove("fstream_named_mutex"); }
} remover;
//Open or create the named mutex
named_mutex mutex(open_or_create, "fstream_named_mutex");
std::ofstream file("file_name");
for(int i = 0; i < 10; ++i){
//Do some operations...
//Write to file atomically
scoped_lock<named_mutex> lock(mutex);
file << "Process name, ";
file << "This is iteration #" << i;
file << std::endl;
}
}
catch(interprocess_exception &ex){
std::cout << ex.what() << std::endl;
return 1;
}
return 0;
Here's what I did to it so I could prove to myself the mutex was doing something:
#include <windows.h>
#include <boost/interprocess/sync/interprocess_mutex.hpp>
#include <boost/lambda/lambda.hpp>
#include <boost/interprocess/sync/scoped_lock.hpp>
#include <boost/interprocess/sync/named_mutex.hpp>
#include <iostream>
#include <iterator>
#include <algorithm>
#include <fstream>
#include <iostream>
#include <cstdio>
int main (int argc, char *argv[])
{
srand((unsigned) time(NULL));
using namespace boost::interprocess;
try{
/*
struct file_remove
{
file_remove() { std::remove("file_name"); }
~file_remove(){ std::remove("file_name"); }
} file_remover;
*/
struct mutex_remove
{
mutex_remove() { named_mutex::remove("fstream_named_mutex"); }
~mutex_remove(){ named_mutex::remove("fstream_named_mutex"); }
} remover;
//Open or create the named mutex
named_mutex mutex(open_or_create, "fstream_named_mutex");
std::ofstream file("file_name");
for(int i = 0; i < 100; ++i){
//Do some operations...
//Write to file atomically
DWORD n1,n2;
n1 = GetTickCount();
scoped_lock<named_mutex> lock(mutex);
n2 = GetTickCount();
std::cout << "took " << (n2-n1) << " msec to acquire mutex";
int randomtime = rand()%10;
if (randomtime<1)
randomtime = 1;
Sleep(randomtime*100);
std::cout << " ... writing...\n";
if (argc>1)
file << argv[1];
else
file << "SOMETHING";
file << " This is iteration #" << i;
file << std::endl;
file.flush(); // added in case this explains the corruption, it does not.
}
}
catch(interprocess_exception &ex){
std::cout << "ERROR " << ex.what() << std::endl;
return 1;
}
return 0;
}
Console Output:
took 0 msec to acquire mutex ... writing...
took 0 msec to acquire mutex ... writing...
took 0 msec to acquire mutex ... writing...
took 0 msec to acquire mutex ... writing...
Also, the demo writes to a file, which if you run two copies of the program will be missing some data.
I expect that if I delete file_name and run two copies of the program, I should get interleaved writes to file_name containing 100 rows from each instance.
(Note, that the demo code is clearly not using an ofstream in append mode, instead it simply rewrites the file each time this program runs, so if we wanted a demo to show two processes writing to a file, I'm aware of that reason why it wouldn't work, but what I did expect is for the above code to be a feasible demonstration of mutual exclusion, which it is not. Also calls to a very handy and aptly named ofstream::flush() method could have been included, and weren't.)
Using Boost 1.53 on Visual C++ 2008
It turns out that Boost is a wonderful library, and it code examples interspersed in the documentation may sometimes be broken. At least the one for boost::interprocess::named_mutex in the docs is not functional on Windows systems.
*Always deleting a mutex as part of the demo code causes the mutex to not function. *
That should be commented in the demo code at the very least. It fails to pass the "principle of least amazement", although I wondered why it was there, I thought it must be idiomatic and necessary, it's idiotic and unnecessary, in actual fact. Or if it's necessary it's an example of what Joel Spolsky would call a leaky abstraction. If mutexes are really filesystem points under C:\ProgramData in Windows I sure don't want to know about it, or know that turds get left behind that will break the abstraction if I don't detect that case and clean it up. (Sure smells like posix friendly semantics for mutexes in Boost have caused them to use a posix-style implementation instead of going to Win32 API directly and implementing a simple mutex that has no filesystem turds.)
Here's a working demo:
#include <windows.h>
#include <boost/interprocess/sync/interprocess_mutex.hpp>
#include <boost/lambda/lambda.hpp>
#include <iostream>
#include <iterator>
#include <algorithm>
#include <boost/interprocess/sync/scoped_lock.hpp>
#include <boost/interprocess/sync/named_mutex.hpp>
#include <fstream>
#include <iostream>
#include <cstdio>
#include <windows.h>
int main (int argc, char *argv[])
{
srand((unsigned) time(NULL));
using namespace boost::interprocess;
try{
/*
// UNCOMMENT THIS IF YOU WANT TO MAKE THIS DEMO IMPOSSIBLE TO USE TO DEMO ANYTHING
struct file_remove
{
file_remove() { std::remove("file_name"); }
~file_remove(){ std::remove("file_name"); }
} file_remover;
// UNCOMMENT THIS IF YOU WANT TO BREAK THIS DEMO HORRIBLY:
struct mutex_remove
{
mutex_remove() { named_mutex::remove("fstream_named_mutex"); }
~mutex_remove(){ named_mutex::remove("fstream_named_mutex"); }
} remover;
*/
//Open or create the named mutex
named_mutex mutex(open_or_create, "fstream_named_mutex");
std::ofstream file("file_name", std::ios_base::app );
int randomtime = 0;
for(int i = 0; i < 100; ++i){
//Do some operations...
//Write to file atomically
DWORD n1,n2;
n1 = GetTickCount();
{
scoped_lock<named_mutex> lock(mutex);
n2 = GetTickCount();
std::cout << "took " << (n2-n1) << " msec to acquire mutex";
randomtime = rand()%10;
if (randomtime<1)
randomtime = 1;
std::cout << " ... writing...\n";
if (argc>1)
file << argv[1];
else
file << "SOMETHING";
file << "...";
Sleep(randomtime*100);
file << " This is iteration #" << i;
file << std::endl;
file.flush();
}
Sleep(randomtime*100); // let the other guy in.
}
}
catch(interprocess_exception &ex){
std::cout << "ERROR " << ex.what() << std::endl;
return 1;
}
return 0;
}
I would love critques and edits on this answer, so that people will have a working demo of using this named mutex .
To use the demo:
- Build it and run two copies of it. Pass a parameter in so you can see which instance wrote which lines (start myexename ABC and start myexename DEF from a command prompt in windows)
- If it's your second run, delete any stray output named "file_name" if you don't want the second run appended to the first.