On Thu, Apr 12, 2012 at 12:23 AM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
HI,
please don't top post on this ML.
Le 11/04/12 18:39, Master a écrit :
Thank you very much :)
for keeping track of my created threads i decided to use thread_groups and accumulate them there . i came up with sth like this :
I told you to use a specific container because thread_group own its threads, so you need to use new or use directly create_thread
boost::thread_group threadstore;
threadstore.add_thread(&thread);
threadstore.add_thread(&thread2);
This doesn't works as explained above.
BOOST_FOREACH(boost::thread t ,threadstore.threads)
{
cout<<t.get_id();
}
well it didnt compiled !
thread_group is not a model of Container so you can not use foreach.
before that , i tried using sth like this which failed nontheless .
vector<boost::thread> threadstore;
I don't know which vector are you using and which version of Boost, but you need to have a vector and a Boost.Thread implementation that supports move semantics. With The trunk version Note that boost::thread is not copyable.
threadstore.push_back(thread);
threadstore.push_back(thread2);
BOOST_FOREACH(boost::thread t ,threadstore)
{
cout<<t.get_id();
}
im clueless of the cause .
Maybe vector<thread*> could respond to your needs.
The threadstore has member called :threads , which i dont know how to work around it , there is also another member named: m ,
which i have no clue of what it is !nor i know where it came form! or what i can do with it!
i couldnt find any information on these members on the boost::thread documentation either
for that example i posted , i moved the mutex inside the loop and then used a sleep() method for couple of microseconds and got it working ( i mean now both threads seem to work as i expected them).
but i want to know if we have sth like , lets say a timed_lock kind of lock !, so that a thread would only hold a mutex for a specified time , and when the timeslice presented in the timed_lock() passes , the affordmentioned thread releases the mutex
and thus other thread(s) can get that mutex and so there would be no need for a sleep() for a thread to wait till it time-slice finishes up and thus releases the mutex .the current timed_lock tries to obtain the mutex in a specified time , which is not the case .
Take a look at the documentation. There are timed_lock, try_lock_for and try_lock_until functions you can use.
i remember i tried to use yield() for achieving such a possiblity (releasing mutex as soon as possible , i think it kinda worked ,i gave a similare result when i used sleep() )
here is the code which i wrote to actually speed up the sum action , which i think didnt give any speed !
You mutex is creating a bottle neck, and the thread are blocking each other, so it is normal you are getting less efficiency. In addition yielding doesn't help you.
would you see where the problem is ?
//in the name of GOD
//Seyyed Hossein Hasan Pour
//Working with Boost::threads
#define BOOST_THREAD_USE_LIB
#include <iostream>
#include <boost/date_time/posix_time/posix_time.hpp>
#include <boost/thread.hpp>
using namespace std;
boost::uint64_t i = 0;
boost::uint64_t sum=0;
boost::mutex mutex;
void IteratorFunc()
{
for (i ; i<100000; i++)
the acces to i in thread unsafe.
{
mutex.lock();
sum+=i;
cout<<i<<"\t"<<boost::this_thread::get_id()<<endl;
mutex.unlock();
//boost::this_thread::sleep(boost::posix_time::microseconds(200));
boost::this_thread::yield();
}
}
int main()
{
boost::posix_time::ptime start = boost::posix_time::microsec_clock::local_time();
boost::thread thread(IteratorFunc);
boost::thread thread2(IteratorFunc);
// boost::thread_group threadstore;
//
// threadstore.add_thread(&thread);
// threadstore.add_thread(&thread2);
//
// BOOST_FOREACH(boost::thread t ,threadstore.threads)
// {
// cout<<t.get_id();
// }
boost::posix_time::ptime end = boost::posix_time::microsec_clock::local_time();
thread.join();
thread2.join();
cout << "sum =\t" << sum<< "\t"<<end-start<<endl;
return 0;
}
i also want to know if we have such a capability where i can specify the priority of a thread or a group of thread against the other threads .
You can do it now using thread_attributes included only on the trunk. Let me know if you need more details.
let me explain it little more, by that i mean , suppose we have couple of reader threads and one or two writer threads , is there any kind of possiblity that i can grant the writer thread(s) more priority in terms of accessing
a resource (by obtaining the mutex more often ? - or the writer thread(s) deny access to readers in some cases ? ) ? or a part of memory ? ( e.g an array of some kind ? )
if it is possible , how can i achieve such possibility ?
Boost.Thread provides shared mutexes that offer you an alternative.
is it possible that i can know if a thread was successful in doing what it was sent to ?
Could you clarify? What are you expecting from the thread. Maybe packaged_task or futures could help you.
can i specify that a thread or a group of thread execute in a specific order ? for example thread one must always execute first and thread two must always follow thread one . do we have such a thing ?
Why do you need this. You need to synchronize your threads to achieve this using condition variable for example.
do i have any means of talking to threads ?
boost::thread has a concrete API. What do you mean by talking to threads?
checking the satus of a specific thread ? or group of threads ?
you can use joinable.
can i know by any means , that which threads are blocked and which are not ?
No that I know.
Thank you so much for your time and please excuse me for such newbish and yet long questions .
i really do appreciate your help and time :)
I suggest you to start using the simple things and grow little by little. Multithreading is not simple at the end.
Maybe you can read the C++ papers that include the motivation and design rationale of C++ Threads.
http://www.boost.org/doc/libs/1_49_0/doc/html/thread.html#thread.overview contains some interesting pointers in particular http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2094.html.
Good luck and welcome,
Vicente