Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Anthony Williams

Pages: 1 ... 4 5 [6]
76
I am not sure if I understand the unique_lock very well. I have this scenerio with the MT algorithm.

I have determined that there is no gain to the algorithm if the generate method has to initialize the threads every time before twisting the array[ 624 ].

I am taking an approach were the contructor creates the threads at the time that the CRandomMT is instantiated. I assign a block of the array to each thread. then I want each thread to stay running for the lifetime of the CRandomMT random number generator. I also want the threads to wait until I queue them to twist there block of the array. then once they are done wait again until they are queued to do it again.

each block of the array is isolated from another block of the array.

does a unique_lock provide this functionality or does it behave differently?

Just to recap: you want the threads to wait for some condition (you want the threads to twist their block of the array), perform their operation and then resume waiting on the condition.

That sounds like a job for a condition variable:

Code: [Select]
std::condition_variable cond;
std::mutex m;
bool do_twist=false;
bool done_twist=false;

void twister_thread(char* array_block_start)
{
    for(;;)
    {
        std::unique_lock<std::mutex> ul(m);
        done_twist=false;
        while(!do_twist)
            cond.wait(ul);
        ul.unlock(); // we don't need to hold the lock whilst we do the twist
        do_twist(array_block_start);
        ul.lock(); // lock the mutex again
        done_twist=true;
    }
}

The controlling thread can then lock the mutex, set do_twist to true and call cond.notify_one() to wake the twisting thread. If you have multiple twisting threads and you want them all to process together, use the same condition variable for all of them and call cond.notify_all() to wake all of them.

77
Your example looks like it should work. Only functions that resize a vector or otherwise copy elements require the contained type to be copyable (so that's resize, push_back, erase, insert, copy-construction and copy assignment of the vector, swap and reserve).

If you know the size of your vector up front then you can pre-allocate it and use move-assignment, as in your example. My previous blanket statement was a bit of a generalization.

78
std::ref is in <functional>, and not supplied by just::thread. With VC9 SP1, std::tr1::ref is included as part of the TR1 package, which has the same functionality. Full support of std::tr1::ref is not provided for just::thread beta v0.4; that will be in beta v0.5

79
I just installed .4 beta and this situation has not been resolved yet. I would suggest the GetNativeSystemInfo function found in the kernel32.dll. when I use this in place of hardware_concurrency I am getting accurate count of processor cores.

Hmm. 0.4 beta is supposed to use that. It returns the correct answer on my XP x64 installation. Thanks for the heads up. I'll investigate next week.

80
Error   4   
error C2558: class 'std::thread' : no copy constructor available or copy constructor is declared 'explicit'
f:\program files (x86)\microsoft visual studio 9.0\vc\include\vector   line 1211

std::thread is movable, but not copyable. This means that you need a move-aware container to be able to store it --- none of the containers shipped with MSVC 2008 are move aware, because every movable-but-not-copyable type does it it's own way. In C++0x move semantics is supported with rvalue references (see my blog entry at http://www.justsoftwaresolutions.co.uk/cplusplus/rvalue_references_and_perfect_forwarding.html), and the standard library containers will have to support such types. For now, we have to write our own.

Quote
I recently aquired your book and was reading through. and I tried using a std::vector with the just::thread class.

Thanks for reading. Not all the examples can be made to work, unfortunately.

81
General Discussion about just::thread / Re: unresolved external symbol
« on: November 20, 2008, 09:23:27 PM »
Thanks!

I thought that was in the 0.3 beta. It will be in the 0.4 beta (tomorrow).

82
amd x2 processor with 4 GB of memory running on vista ultimate x64

the below code I have found is far more accurate on my system. it uses the GetNativeSystemInfo found in the kernel32.dll  and returns 2 for the dwNumberOfProcessors everytime. to be honest based on the code below I have never ran GetSystemInfo on my computer because GetNativeSystemInfo has been successfull every time I have ran this code.

Aha. GetSystemInfo is documented to return incorrect information under WOW64, which you get with a 32-bit app on a 64-bit OS.

I bet that's the problem with the deadlock check stack tracing too --- WOW64 is messing up the stack tracer. I'll see what I can do.

Thanks.

83
General Discussion about just::thread / Re: break error on t.join()
« on: November 19, 2008, 10:00:43 PM »
here is the call stack:

>   msvcr90d.dll!_NMSG_WRITE(int rterrnum=10)  Line 198   C
    msvcr90d.dll!abort()  Line 59 + 0x7 bytes   C
    msvcr90d.dll!terminate()  Line 130   C++

...

   Parallel.exe!std::unique_lock<std::mutex>::unique_lock<std::mutex>(std::mutex & m_={...})  Line 261   C++
    Parallel.exe!CLock::CLock(std::mutex & _m={...})  Line 19 + 0xf bytes   C++
 

The fact that the code is stopped in terminate implies that stack trace function used by the deadlock detection hit an unrecoverable internal error. Why that would happen is currently beyond me. I will have to investigate further. Thank you for reporting this.

What version of Windows are you running? Which edition of MSVC (express, standard, team system ...)?

The later part of the stack trace doesn't seem to match the source code you've pasted. Did you try using something other than lock_guard (e.g. unique_lock as posted?) It doesn't matter; just trying to identify the discrepancy.

Thanks.

84
based on the documentation you mentioned that this should return the number of processors.

so I was expecting it to return '2'. I was surprised to recieve the number '2036182'.

which leads to the question of how that number was picked and why?

Wow, you've got a lot of processors in your system ;-)

This function uses the
Code: [Select]
GetSystemInfo Windows API call, which supposedly cannot fail. On my dual-core machines it returns "2". What system are you running on?

85
General Discussion about just::thread / Re: Beta 0.3 build errors
« on: November 19, 2008, 08:08:07 AM »
I followed the instructions for adding the include and lib to my path.

I created a console application x86. I then added the header <thread> and <mutex>

I had 6 build errors and 4 warnings.

Warning   1   
warning C4003: not enough actual parameters for macro 'min'   
c:\program files (x86)\justsoftwaresolutions\justthread\include\jss\config.hpp   282   Parallel

these errors occured with the <windows.h> header included

I would appreciate any advice you may have on how to deal with these errors?

Kenneth

Thanks for reporting the problem. Please replace <InstallDir>/include/jss/config.hpp with the version attached to this message. It will be included in beta 0.4, which will be out this week.

86
I am pleased to announce the third beta release (v0.3) of the
just::thread C++0x standard thread library implementation.

The library offers a complete implementation of the C++0x standard
thread library for users of Microsoft Visual Studio 2008 and Microsoft
Visual C++ Express 2008 for 32-bit Windows targets.

Changes since beta 0.2:

  • Improvements to deadlock detection mode --- deadlocks detected in more scenarios, and better debug information given;
  • Improved implementation of std::ratio support classes used by std::chrono::duration;
  • Better resolution for std::chrono::monotonic_clock;
  • Added conversion to/from time_t for std::chrono::system_clock::time_point;
  • More extensive documentation.

Sign up to this forum and download the beta today!

All beta testers will receive a 25% discount on the final library.

87
The 0.2 beta release of just::thread is now available. If you would like to test it, please sign up for this forum and go to the Beta Releases discussion board, where it is available for download.

This beta includes the following features missing from the previous beta:

  • Basic documentation
  • Support for additional arguments to the thread constructor
  • Added the missing <stdatomic.h> header.
  • Added missing typedefs to the <cstdatomic> header.
  • Optimized thread class to minimize the number of times the supplied function and arguments are copied.
  • Added new deadlock-detection facility (define _JUST_THREAD_DEADLOCK_CHECK when building).

88
General Discussion about just::thread / Re: Just a few questions
« on: October 16, 2008, 01:42:05 PM »
There are some examples in my introduction to the C++0x thread library on DevX: http://www.devx.com/SpecialReports/Article/38883

Here's a simple example program that launches two threads:

Code: [Select]
#include <thread>
#include <mutex>
#include <iostream>
#include <chrono>

std::mutex iom;

void thread_func(int id)
{
    for(unsigned i=0;i<1000;++i)
    {
        std::this_thread::sleep_for(std::chrono::milliseconds(1));
       
        std::lock_guard<std::mutex> lk(iom);
        std::cout<<"Thread "<<id<<" ";
    }
}


int main()
{
    std::thread t1(thread_func,1);
    std::thread t2(thread_func,2);
    t2.join();
    t1.join();
}

89
V0.1 Beta of just::thread has been released today. If you wish to take part in the beta program, please contact beta@stdthread.co.uk.

Pages: 1 ... 4 5 [6]