Hello, I am in need of a lock free fifo for my current project so I looked into lockfree. However, in the documentation I see: boost.lockfree has been tested on the following platforms: a.. g++ 4.4, 4.5 and 4.6, linux, x86 & x86_64 b.. clang++ 3.0, linux, x86 & x86_64 My question is what the status is on Windows? The documentation for boost.atomic says that Windows has been tested, so is there a reason why lockfree might have platform specific issues? When I run the example provided for the single producer/single consumer queue, I get the expected results so it does seem to work. It also states that the queue is lock free. Is it safe to use on Windows at present? Thanks in advance for any information. Kind regards, Philip Bennefall
I am in need of a lock free fifo for my current project so I looked into lockfree. However, in the documentation I see:
boost.lockfree has been tested on the following platforms: a.. g++ 4.4, 4.5 and 4.6, linux, x86 & x86_64 b.. clang++ 3.0, linux, x86 & x86_64
My question is what the status is on Windows? The documentation for boost.atomic says that Windows has been tested, so is there a reason why lockfree might have platform specific issues? When I run the example provided for the single producer/single consumer queue, I get the expected results so it does seem to work. It also states that the queue is lock free. Is it safe to use on Windows at present?
if you tested it and it works, you are probably fine. the mentioned compilers are the once that i had been testing before the review. according to [1], there are some test failures on windows, though most of these cases seem to be related to timeouts of the stress tests. the main reason for not mentioning windows/msvc is that i cannot test on these platforms myself ... tim [1] http://www.boost.org/development/tests/trunk/developer/lockfree.html
----- Original Message -----
From: "Tim Blechmann"
I am in need of a lock free fifo for my current project so I looked into lockfree. However, in the documentation I see:
boost.lockfree has been tested on the following platforms: a.. g++ 4.4, 4.5 and 4.6, linux, x86 & x86_64 b.. clang++ 3.0, linux, x86 & x86_64
My question is what the status is on Windows? The documentation for boost.atomic says that Windows has been tested, so is there a reason why lockfree might have platform specific issues? When I run the example provided for the single producer/single consumer queue, I get the expected results so it does seem to work. It also states that the queue is lock free. Is it safe to use on Windows at present?
if you tested it and it works, you are probably fine. the mentioned compilers are the once that i had been testing before the review. according to [1], there are some test failures on windows, though most of these cases seem to be related to timeouts of the stress tests. the main reason for not mentioning windows/msvc is that i cannot test on these platforms myself ... tim Thank you for the quick response, Tim! My only concern is the "probably" part. I want to use this in production code that is meant to ship on several platforms including Windows, so I am a little hesitant to do so if it's "probably fine". Has anyone used Boost Lockfree in production code on Windows? If so, were there any problems? I am only interested in spsc_queue, which looks like it'll do just what I want (streaming audio). Kind regards, Philip Bennefall
Thank you for the quick response, Tim! My only concern is the "probably" part. I want to use this in production code that is meant to ship on several platforms including Windows, so I am a little hesitant to do so if it's "probably fine". Has anyone used Boost Lockfree in production code on Windows? If so, were there any problems? I am only interested in spsc_queue, which looks like it'll do just what I want (streaming audio).
again `probably': probably it is used in production code ... usually people don't report if they use code which works fine, but just complain when experiencing bugs ... in german there is a saying: `evidence, not eminence' ... not sure if it translates, but it means something like: in doubt review the code and perform tests instead of trusting the opinion of guru's ... ;) cheers, tim
participants (2)
-
Philip Bennefall -
Tim Blechmann