[med-svn] [Git][med-team/readerwriterqueue][upstream] New upstream version 1.0.3
Nilesh Patra
gitlab at salsa.debian.org
Thu Sep 24 18:00:44 BST 2020
Nilesh Patra pushed to branch upstream at Debian Med / readerwriterqueue
Commits:
b8e6812a by Nilesh Patra at 2020-09-24T22:05:02+05:30
New upstream version 1.0.3
- - - - -
6 changed files:
- + CMakeLists.txt
- README.md
- atomicops.h
- readerwriterqueue.h
- tests/stabtest/makefile
- tests/unittests/unittests.cpp
Changes:
=====================================
CMakeLists.txt
=====================================
@@ -0,0 +1,9 @@
+cmake_minimum_required(VERSION 3.9)
+project(readerwriterqueue VERSION 1.0.0)
+
+include(GNUInstallDirs)
+
+add_library(${PROJECT_NAME} INTERFACE)
+
+install(FILES atomicops.h readerwriterqueue.h LICENSE.md
+ DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/${PROJECT_NAME})
=====================================
README.md
=====================================
@@ -64,14 +64,18 @@ BlockingReaderWriterQueue<int> q;
std::thread reader([&]() {
int item;
+#if 1
for (int i = 0; i != 100; ++i) {
// Fully-blocking:
q.wait_dequeue(item);
-
+ }
+#else
+ for (int i = 0; i != 100; ) {
// Blocking with timeout
if (q.wait_dequeue_timed(item, std::chrono::milliseconds(5)))
++i;
}
+#endif
});
std::thread writer([&]() {
for (int i = 0; i != 100; ++i) {
@@ -90,7 +94,22 @@ means care must be taken to only call `wait_dequeue` if you're sure another elem
will come along eventually, or if the queue has a static lifetime. This is because
destroying the queue while a thread is waiting on it will invoke undefined behaviour.
-
+## CMake installation
+As an alternative to including the source files in your project directly,
+you can use CMake to install the library in your system's include directory:
+
+```
+mkdir build
+cd build
+cmake ..
+make install
+```
+
+Then, you can include it from your source code:
+```
+#include <readerwriterqueue/readerwriterqueue.h>
+```
+
## Disclaimers
The queue should only be used on platforms where aligned integer and pointer access is atomic; fortunately, that
=====================================
atomicops.h
=====================================
@@ -537,8 +537,8 @@ namespace moodycamel
const int usecs_in_1_sec = 1000000;
const int nsecs_in_1_sec = 1000000000;
clock_gettime(CLOCK_REALTIME, &ts);
- ts.tv_sec += usecs / usecs_in_1_sec;
- ts.tv_nsec += (usecs % usecs_in_1_sec) * 1000;
+ ts.tv_sec += (time_t)(usecs / usecs_in_1_sec);
+ ts.tv_nsec += (long)(usecs % usecs_in_1_sec) * 1000;
// sem_timedwait bombs if you have more than 1e9 in tv_nsec
// so we have to clean things up before passing it in
if (ts.tv_nsec >= nsecs_in_1_sec) {
@@ -588,7 +588,7 @@ namespace moodycamel
// Is there a better way to set the initial spin count?
// If we lower it to 1000, testBenaphore becomes 15x slower on my Core i7-5930K Windows PC,
// as threads start hitting the kernel semaphore.
- int spin = 10000;
+ int spin = 1024;
while (--spin >= 0)
{
if (m_count.load() > 0)
@@ -602,8 +602,11 @@ namespace moodycamel
if (oldCount > 0)
return true;
if (timeout_usecs < 0)
- return m_sema.wait();
- if (m_sema.timed_wait(timeout_usecs))
+ {
+ if (m_sema.wait())
+ return true;
+ }
+ if (timeout_usecs > 0 && m_sema.timed_wait(timeout_usecs))
return true;
// At this point, we've timed out waiting for the semaphore, but the
// count is still decremented indicating we may still be waiting on
=====================================
readerwriterqueue.h
=====================================
@@ -58,7 +58,7 @@
namespace moodycamel {
template<typename T, size_t MAX_BLOCK_SIZE = 512>
-class ReaderWriterQueue
+class AE_ALIGN(MOODYCAMEL_CACHE_LINE_SIZE) ReaderWriterQueue
{
// Design: Based on a queue-of-queues. The low-level queues are just
// circular buffers with front and tail indices indicating where the
@@ -727,10 +727,10 @@ private:
}
private:
- weak_atomic<Block*> frontBlock; // (Atomic) Elements are enqueued to this block
+ weak_atomic<Block*> frontBlock; // (Atomic) Elements are dequeued from this block
char cachelineFiller[MOODYCAMEL_CACHE_LINE_SIZE - sizeof(weak_atomic<Block*>)];
- weak_atomic<Block*> tailBlock; // (Atomic) Elements are dequeued from this block
+ weak_atomic<Block*> tailBlock; // (Atomic) Elements are enqueued to this block
size_t largestBlockSize;
@@ -788,6 +788,19 @@ public:
return false;
}
+#if MOODYCAMEL_HAS_EMPLACE
+ // Like try_enqueue() but with emplace semantics (i.e. construct-in-place).
+ template<typename... Args>
+ AE_FORCEINLINE bool try_emplace(Args&&... args) AE_NO_TSAN
+ {
+ if (inner.try_emplace(std::forward<Args>(args)...)) {
+ sema->signal();
+ return true;
+ }
+ return false;
+ }
+#endif
+
// Enqueues a copy of element on the queue.
// Allocates an additional block of memory if needed.
@@ -813,6 +826,19 @@ public:
return false;
}
+#if MOODYCAMEL_HAS_EMPLACE
+ // Like enqueue() but with emplace semantics (i.e. construct-in-place).
+ template<typename... Args>
+ AE_FORCEINLINE bool emplace(Args&&... args) AE_NO_TSAN
+ {
+ if (inner.emplace(std::forward<Args>(args)...)) {
+ sema->signal();
+ return true;
+ }
+ return false;
+ }
+#endif
+
// Attempts to dequeue an element; if the queue is empty,
// returns false instead. If the queue has at least one element,
=====================================
tests/stabtest/makefile
=====================================
@@ -12,6 +12,7 @@ else
EXT=
PLATFORM_OPTS=
PLATFORM_LD_OPTS=-lrt -Wl,--no-as-needed
+ endif
endif
default: stabtest$(EXT)
=====================================
tests/unittests/unittests.cpp
=====================================
@@ -567,6 +567,21 @@ public:
ASSERT_OR_FAIL(!q.wait_dequeue_timed(item, 1));
ASSERT_OR_FAIL(result.load());
}
+
+#if MOODYCAMEL_HAS_EMPLACE
+ {
+ BlockingReaderWriterQueue<UniquePtrWrapper> q(100);
+ std::unique_ptr<int> p { new int(123) };
+ q.emplace(std::move(p));
+ q.try_emplace(std::move(p));
+ UniquePtrWrapper item;
+ ASSERT_OR_FAIL(q.wait_dequeue_timed(item, 0));
+ ASSERT_OR_FAIL(item.get_value() == 123);
+ ASSERT_OR_FAIL(q.wait_dequeue_timed(item, 0));
+ ASSERT_OR_FAIL(item.get_ptr() == nullptr);
+ ASSERT_OR_FAIL(q.size_approx() == 0);
+ }
+#endif
return true;
}
View it on GitLab: https://salsa.debian.org/med-team/readerwriterqueue/-/commit/b8e6812a719f84ea890548f53d6f6d093e8dfb31
--
View it on GitLab: https://salsa.debian.org/med-team/readerwriterqueue/-/commit/b8e6812a719f84ea890548f53d6f6d093e8dfb31
You're receiving this email because of your account on salsa.debian.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/debian-med-commit/attachments/20200924/04fa204c/attachment-0001.html>
More information about the debian-med-commit
mailing list