Bill Lear: "Re: store vector<> to filesystem (newbie question)"

Bill, it is the same message with different subject. I'm not sure if previous will show up on this thread as a respond to your sending. -----Original Message----- From: Gennady Khokhorin Sent: Wednesday, April 18, 2007 2:45 PM To: 'boost-users@lists.boost.org' Subject: Re: store vector<> to filesystem (newbie question)
template<typename Archive> struct Serializer { static void save(const vector<double>& timeStamps) { std::ofstream ofs("file.bin", std::ios::binary);
Archive oa(ofs); oa << timeStamps; } };
Serializer
::save(timeStamps);
Thanks, Bill, for your fast respond!
Started reading serialization.
Did try to use serialization from your sample, got stuck with error message:
Error 20 error C2039: 'serialize' : is not a member of 'std::vector<_Ty>' c:\boost\include\boost-1_33_1\boost\serialization\access.hpp 109
Is it restriction sign for using std::vector<> with << operator or I'm missing some headers?
my settings:
#include

On Wednesday, April 18, 2007 at 16:18:25 (-0800) Gennady Khokhorin writes:
Is it restriction sign for using std::vector<> with << operator or I'm missing some headers?
You're missing some headers. There is an example program in the boost distribution that should lead you to the answer. Don't have time to write one up right now, sorry. Bill

On Apr 13, 2007, PJ Durai wrote:
I have two threads waiting on a condition. When I call condition::notify_all() from the main thread, I expected both threads to fall through and proceed simultaneously.
But that is not what I am witnessing. They behave like I had called condition::notify_one() twice.
One thread continues, does its thing (in this case a simple Sleep and a printf) comes back to wait. Only after that point the second thread continued from the condition.
Is this expected ? What am I missing ?
Its possible. notify_all() will make the threads ready to run, its up to the OS as to when they actually run. So if the Sleep is short enough, what you observe could happen. On a win32 platform, though, I would expect the second thread to wake when the first encounters the Sleep().
I can post the code if anyone wants to take a look.
Yes, this would help. Ken Krovchuck

On 4/18/07, Ken
On Apr 13, 2007, PJ Durai wrote:
I have two threads waiting on a condition. When I call condition::notify_all() from the main thread, I expected both threads to fall through and proceed simultaneously.
But that is not what I am witnessing. They behave like I had called condition::notify_one() twice.
One thread continues, does its thing (in this case a simple Sleep and a printf) comes back to wait. Only after that point the second thread continued from the condition.
Is this expected ? What am I missing ?
Its possible. notify_all() will make the threads ready to run, its up to the OS as to when they actually run. So if the Sleep is short enough, what you observe could happen. On a win32 platform, though, I would expect the second thread to wake when the first encounters the Sleep().
I can post the code if anyone wants to take a look.
Yes, this would help.
Ken Krovchuck
Thanks Ken.
Here is the reproducing piece of code. This is compilable. Just paste
it into a cpp file and compile in a MSVC 2005 command prompt. Here is
the compilation command I used..
======
build.bat
======
cl threadtest1.cpp /I "C:\Boost\include\boost-1_33_1" /D
_CRT_SECURE_NO_DEPRECATE /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D
"_UNICODE" /D "UNICODE" /EHsc /W3 /nologo /MDd /link
/LIBPATH:"c:\Boost\lib"
Please run threadtest1.exe and hit 'g' to observe the behaviour.
========
output (they are firing one after another..)
========
C:\home\pjdurai\dev\boosttest>threadtest1
thread0 : waiting ...
thread1 : waiting ...
thread0 : before cond wait...
thread1 : before cond wait...
thread1 : after cond wait...
thread1 : doing stuff...
1111111111
thread1 : waiting ...
thread0 : after cond wait...
thread1 : before cond wait...
thread0 : doing stuff...
0000000000
thread0 : waiting ...
thread0 : before cond wait...
===========
threadtest1.cpp
===========
#include

PJ Durai wrote:
On 4/18/07, Ken
wrote: On Apr 13, 2007, PJ Durai wrote:
I have two threads waiting on a condition. When I call condition::notify_all() from the main thread, I expected both threads to fall through and proceed simultaneously.
But that is not what I am witnessing. They behave like I had called condition::notify_one() twice.
One thread continues, does its thing (in this case a simple Sleep and a printf) comes back to wait. Only after that point the second thread continued from the condition.
Is this expected ? What am I missing ?
This is expected. condition::wait reacquires the mutex after it returns. You then call Sleep(4000) with the mutex locked; the other threads can't continue because they are waiting for the mutex. Try unlocking lk before Sleep'ing.

On 4/19/07, Peter Dimov
PJ Durai wrote:
On 4/18/07, Ken
wrote: On Apr 13, 2007, PJ Durai wrote:
I have two threads waiting on a condition. When I call condition::notify_all() from the main thread, I expected both threads to fall through and proceed simultaneously.
But that is not what I am witnessing. They behave like I had called condition::notify_one() twice.
One thread continues, does its thing (in this case a simple Sleep and a printf) comes back to wait. Only after that point the second thread continued from the condition.
Is this expected ? What am I missing ?
This is expected. condition::wait reacquires the mutex after it returns. You then call Sleep(4000) with the mutex locked; the other threads can't continue because they are waiting for the mutex. Try unlocking lk before Sleep'ing.
Thanks peter. That fixed it. My loop looks like this now. And it is working as expected. void operator() () { while(1) { { TRACE("%s : waiting ...\n", name.c_str()); { TRACE("%s : before cond wait...\n", name.c_str()); { boost::mutex::scoped_lock lk(mutex); cond.wait(lk); } TRACE("%s : after cond wait...\n", name.c_str()); { TRACE("%s : doing stuff...\n", name.c_str()); //ElapsedTime etime(name.c_str()); Sleep(4000); for (int i=0; i<10; ++i) std::cout << id; std::cout << std::endl; } } } //barrier.wait(); } } Thanks Guys.
participants (5)
-
Bill Lear
-
Gennady Khokhorin
-
Ken
-
Peter Dimov
-
PJ Durai