Messages

31

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

« on: November 19, 2011, 12:47:35 AM »

I am not sure why it is not working for you.

Probably the easiest option in the short term is to specify the path directly:

g++ -m32 -mthreads -std=c++0x -Ie:/justthread/include foo.cpp -o foo.exe e:/justthread/lib/libjustthread32.a -lwinmm

32

General Discussion about just::thread / Re: Problems with dynamically loaded DLLs and with recursive_mutex

« on: November 09, 2011, 09:29:19 PM »

PROBLEM #1
When a DLL using justthread_check_vc10x64_mdd.lib is dynamically loaded with LoadLibrary, we get a crash.

PROBLEM #2
With justthread_vc10x64_mdd.lib (since we're a bit stuck with the check version), there is another problem.

I get a crash in a thread that has not been started using std::thread and that is trying tu use a recursive_mutex:

This thread was created before obase.dll (that uses JustThread) was loaded. Someone here suspects that it is related to that fact. We had a similar problem with Thread Local Storage a couple of years ago: when declaring a TLS in a DLL using Microsoft approach, the storage was not automatically created for threads that existed prior to loading that DLL, we had to implement something for that special case.

This does sound like a TLS issue in both cases. The "check" library uses TLS for keeping track of the check data, and recursive_mutex uses TLS for fast recursive locking. I thought we'd avoided the Microsoft TLS problems, but it would appear not. I'll add some more test cases for dynamically-loaded DLLs to our test suite and issue a fix for 1.7.3.

33

General Discussion about just::thread / Re: Warning LNK4099 when linking with *check* library

« on: November 05, 2011, 11:20:44 AM »

This issue should be fixed in V1.7.2

34

General Discussion about just::thread / Re: Warning LNK4099 when linking with *check* library

« on: November 02, 2011, 08:44:20 AM »

The debug info for the checked libraries should be provided. I'll check the installer packaging and get back to you.

35

General Discussion about just::thread / Re: Need on help on hardware_concurrency

« on: October 19, 2011, 03:58:12 PM »

You also need to link against librt if you're using the static library

g++ -O2 -o hardware testHardware.cpp -I/usr/include/justthread -L/usr/lib64/ -ljustthread -pthread -lrt

I am surprised that the shared library libjustthread.so (which automatically pulls in librt) isn't being used though.

36

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

« on: October 10, 2011, 12:40:00 PM »

I am pleased to announce that version 1.7.0 of Just::Thread has been released.

This release adds official support for gcc v4.4 on Centos 6, so Just::Thread is now supported on Centos, Fedora, Ubuntu and Debian Linux distributions, as well as Microsoft Windows and Apple MacOSX.

The main change with this release is an enhancement to the std::async implementation. With this enhanced scheduler, the default launch policy (std::launch::async | std::launch::deferred) will defer forcing a decision until either enough resources become available to schedule the task as std::launch::async, or the task is forced to be scheduled as std::launch:deferred by a call to a waiting function (get(), wait(), wait_for() or wait_until()). This will allow more tasks to be scheduled as std::launch::async overall, and allow your application to make better use of the available hardware concurrency.

The implementation of recursive mutexes has been overhauled, leading to much faster lock and unlock times than in previous releases.

This release also provides debugger visualizers for Microsoft Visual Studio, to better show the state of Just::Thread objects such as futures. This will provide greater insight into the state of your program, and allow easier debugging.

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

37

General Discussion about just::thread / Re: #define _AMD64_

« on: October 10, 2011, 12:30:59 PM »

Thanks for the report; this fix will be in the next release.

38

General Discussion about just::thread / Re: Unable to link on Snow Leopard (Xcode 3.2.6)

« on: August 23, 2011, 06:16:43 PM »

Sorry about the problem you encountered with uploading an attachment.

With regards to your problem, it should just be a matter of doing a Clean from the Build menu in XCode. For some reason, XCode had built an x86_64 object file from main.cpp, but wasn't rebuilding it for i386.

If you are still having problems, let me know.

39

General Discussion about just::thread / Re: Unable to link on Snow Leopard (Xcode 3.2.6)

« on: August 23, 2011, 03:57:37 PM »

It does seem like the linker is trying to link an x86_64 binary. Can you post a sample project that demonstrates the problem?

40

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

« on: August 22, 2011, 09:43:59 AM »

I am pleased to announce that version 1.6.1 of just::thread has been released.

Changes include:

• Updated API to conform to the Final C++0x Standard draft
• Support for gcc 4.6 on Ubuntu Natty (using the packages from the Ubuntu Toolchain PPA), Fedora 15 and MacOSX.
• Support for thread-local variables with non-trivial constructors and destructors using the JSS_THREAD_LOCAL macro in place of the new thread_local keyword (which is not supported in any current compilers) .
• The std::hash<std::thread::id> specialization has been added.
• The new constexpr and noexcept keywords are used where supported (gcc 4.6 in -std=c++0x mode.)
• The return type of lambda functions is correctly deduced in std::async in both gcc 4.5 and 4.6 and MSVC 2010.
• Various optimizations, including reduction in thread creation code and the overhead of std::async.
• Added std::chrono::system_clock::from_time_t in place of std::chrono::system_clock::to_time_point.

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

41

General Discussion about just::thread / Re: Source Code Availability

« on: August 22, 2011, 09:31:45 AM »

The source code for the library is not generally available for purchase.

Requests will be considered on a case by case basis.

42

General Discussion about just::thread / Re: ATOMIC_VAR_INIT

« on: February 17, 2011, 03:35:58 PM »

Could you please explain what ATOMIC_VAR_INIT is used for? I couldn't find any useful information on that (or maybe I just coulnd't get it). As far as I understood it is used to initialize atomic variables in some special way, but what kind of initialization is done? When it might be useful? All the examples I could find was
atomic<int> t = ATOMIC_VAR_INIT(2);
why not just
atomic<int> t = 2;
what's the difference?

ATOMIC_VAR_INIT is there for C compatibility, since you can't write

Code: [Select]

atomic_int i(3);
in C, but you can write

Code: [Select]

atomic_int i=ATOMIC_VAR_INIT(3);
in both C and C++.

43

General Discussion about just::thread / Re: unaligned atomic variables

« on: February 17, 2011, 03:18:23 PM »

Another thing that can be done is putting atomic classes between

Code: [Select]

#pragma pack(push)
#pragma pack(4)
// class atomic ...
#pragma pack(pop)


That wouldn't help: it just affects the layout of the atomic objects, not the alignment of the whole object.

44

General Discussion about just::thread / Re: unaligned atomic variables

« on: February 17, 2011, 03:16:06 PM »

hmmm..
#pragma pack affects default alignment, but it shouldn't affect explicit alignment.
This code outputs 8 for the size and true for is_aligned call on my machine inspite of #pragma pack(1).

Code: [Select]

#include <iostream>

#pragma pack(1)

struct X
{
char a;
__declspec (align(4)) long b;
};

bool is_aligned(void *ptr, int boundary)
{
return ((uintptr_t)ptr & (boundary - 1)) == 0;
}


int main()
{
X x;
std::cout << sizeof(X) << std::endl;
std::cout << is_aligned(&x.b, 4) << std::endl;
}
I'm not sure about gcc.
Anyway, if this is not portable enough then assert is good solution too.

MSVC is inconsistent: with #pragma pack(1) it obeys the alignment requirements sometimes, but not others.

gcc always ignores alignment requirements with #pragma pack(1).

I'll put asserts in the atomic ops.

45

General Discussion about just::thread / Re: unaligned atomic variables

« on: February 17, 2011, 02:50:47 PM »

Yes, I guess you have a base class where the actual data is stored. The constructor might do that check. Alternatively you can do something like this

Code: [Select]

template <typename T>
class atomic_base {
   // T data;
   __declspec (align(4)) T data;
};


The code already does that, so everything will be correctly aligned by default. However, if you use #pragma pack(1) then you're deliberately asking the compiler to ignore such alignment specifications, so it doesn't help.