Messages

16

General Discussion about just::thread / Re: jss::synchronized_value

« on: April 23, 2013, 12:13:46 PM »

Yes, there's a potential race between the test and the set. It's "safe" in the sense that the mutex is held across each access, but it might overwrite a change made by another thread.

This is a dummy example. Probably not a very good one 

jss::update_guard is the companion to jss::synchronized_value that allows safe accesses across multiple statements:

Code: [Select]

jss::synchronized_value<std::string> sv;

void bar(){
    jss::update_guard<std::string> guard(sv);
    if(guard->empty()){
        *guard="hello"; // no potential for a race here.
    }
}


17

General Discussion about just::thread / ANNOUNCE: Just::Thread V1.8.0 Released

« on: August 30, 2012, 05:42:45 PM »

I am pleased to announce that Just::Thread V1.8.0 has been released.

This version now supports Microsoft Visual Studio 2012, so you can continue to benefit from Just::Thread when upgrading your compiler.

There are also minor fixes and improvements that affect all platforms.

As usual, existing customers are entitled to a free upgrade to V1.8.0 from all earlier versions.

18

General Discussion about just::thread / Re: Access Violation using 1.7.3 or 1.7.4 in dynamically loded Windows DLL

« on: August 20, 2012, 10:53:23 AM »

That's a known issue with those releases. I've just updated everyone to V1.7.4.1 (Windows only release), which should fix this problem.

Please download the new version and try again. If there is still a problem, then I'll investigate further.

19

General Discussion about just::thread / Re: Need justthread for debian armel

« on: August 13, 2012, 08:35:58 AM »

Just::Thread is not available for ARMEL at the moment. Porting to ARMEL is more than just a recompile, since the assembly code must be changed. It is currently on the "future plans" list, but with no due date.

If you upgrade to a site licence then I will move this port to the top of the list, and start work on it. If you need it really urgently, you can pay for a custom port.

20

General Discussion about just::thread / Re: creating a thread using a class member function

« on: July 30, 2012, 07:34:28 AM »

To create a thread using a class member function you need to pass a "this" pointer as the second parameter to the std::thread constructor:

Code: [Select]

a an_a_object;
std::thread dosomething(&a::afunction, &an_a_object,32); // a pointer to an a
std::thread t2(&a::function,std::ref(an_a_object),32); // a reference wrapped in std::ref
std::thread t3(&a::function,a(),32); // an rvalue, which is copied/moved into the thread storage

You might like to see my Multithreading in C++0x tutorial series. Member functions are covered in Part 3: Starting Threads with Member Functions and Reference Arguments

21

General Discussion about just::thread / Re: Lambda functions

« on: July 27, 2012, 08:30:04 AM »

Yes, if your compiler supports lambda functions (e.g. MSVC2010, g++ 4.6) then you can use them with the library. e.g.

Code: [Select]

std::thread t(
    []{
        do_something();
        do_something_else();
    });

22

General Discussion about just::thread / Re: managed C++ crash

« on: May 08, 2012, 12:59:21 PM »

Possibly. I'll look into the implementation changes that would be required.

23

General Discussion about just::thread / Re: mutex - owning thread?

« on: May 08, 2012, 12:58:15 PM »

No, there isn't. The normal build of the library does not track this information. The checked build does, but this is not available outside the deadlock-detection code. For one thing, it could change between the call being made and the information being used.

24

General Discussion about just::thread / Re: managed C++ crash

« on: January 24, 2012, 08:42:24 AM »

The restriction is that a mixed-mode or managed DLL cannot contain TLS callbacks.

Just::Thread uses TLS callbacks to ensure that the process-wide and thread-specific data it uses is correctly constructed and destroyed, so it cannot be used in a mixed-mode DLL.

Note that this is about the DLL itself, not the process: Just::Thread can be used in a native DLL called from managed code without problems, as you have discovered.

25

General Discussion about just::thread / Re: managed C++ crash

« on: January 23, 2012, 09:27:00 PM »

Just::Thread does not work with managed or mixed-mode code since it uses thread-exit callbacks which are not supported for executables and DLLs containing managed code.

26

General Discussion about just::thread / ANNOUNCE: Just::Thread 1.7.3 released

« on: January 10, 2012, 06:15:25 PM »

I am pleased to announce that version 1.7.3 of Just::Thread has been released, with the following changes:

• The TDM port of gcc v4.6.1 for Windows is now supported
• gcc v4.6.2 on Fedora 16 is now supported
• std::thread::id is now a proper nested class rather than a typedef to a namespace-level class.
• Just::Thread can now be used within a dynamically-loaded DLL on Windows

As usual, existing customers are entitled to a free upgrade to V1.7.3 from all earlier versions.

27

General Discussion about just::thread / Re: Support for wait_for_any?

« on: January 03, 2012, 10:21:56 AM »

Just::Thread doesn't support wait_for_any() at the moment. As you say, it's not something required by C++11, and the Boost.Thread implementation imposes overhead on the futures even if they are not used in wait_for_any.

It's something I'm considering adding when I can think of a low-overhead implementation.

28

General Discussion about just::thread / Re: Trying to get to 1st base with TDM gcc4.5.2 under WinXP

« on: November 22, 2011, 07:29:10 PM »

There's a separate installer for the 32/64-bit version. The libjustthread32.a and libjustthread64.a libraries were built with that.

Right, but from what I'm seeing (and I admit I don't always see things correctly, esp. when gcc is concerned...) is that the 32/64-bit version is ONLY a 4.6.1 option

The 32/64-bit installer for 4.5.2 is at http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/Previous/1.1006.0/tdm64-gcc-4.5.2.exe/download

29

General Discussion about just::thread / Re: Trying to get to 1st base with TDM gcc4.5.2 under WinXP

« on: November 22, 2011, 08:05:24 AM »

Hi Leor,

First the easy bit:

Which leads me to wonder why you refer to the 32/64-bit version in your README file, since that only seems to be applicable to 4.6.1

There's a separate installer for the 32/64-bit version. The libjustthread32.a and libjustthread64.a libraries were built with that.

It runs fine under VC9, but under TDM4.5.2 I get the following "bonus" output after the expected two lines:

terminate called after throwing an instance of 'std::system_error'
  what():

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

What's that about?

That's a bug I just discovered this week. The internals of the library need to be destroyed in the right order, and sometimes the TDM linker destroys things in the wrong order, causing this problem. This is a bug that only applies to the TDM build as far as I can see. I'm working on a fix.

Sorry for the inconvenience; it seems you've hit more than your share of problems 

30

General Discussion about just::thread / Re: Trying to get to 1st base with TDM gcc4.5.2 under WinXP

« on: November 21, 2011, 08:29:28 AM »

When I provide the full pathname as per your suggestion (or, in fact, copy the required .a file to the current directory and give its name without any path at all), it does not seem to resolve any symbols. The result of attempting the compilation is now:

c:\temp\ccb20mvj.o:thread1.cpp:(.text+0x9a): undefined reference to `std::__jssX
46::thread::join()'

This symbol will not be resolved by the current release of just::thread. The name indicates that this code was compiled with gcc 4.6, which is not supported for the TDM port. I guess your PATH still has TDM 4.6.1 on it.