Menu
▾
▴
loki-lib-general — A mailing list for the Loki library and related topics.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(4) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(3) |
Dec
|
| 2005 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(15) |
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(2) |
Dec
(15) |
| 2006 |
Jan
(44) |
Feb
(71) |
Mar
(67) |
Apr
(21) |
May
(35) |
Jun
(7) |
Jul
(19) |
Aug
(7) |
Sep
(14) |
Oct
(48) |
Nov
(14) |
Dec
(3) |
| 2007 |
Jan
(4) |
Feb
(11) |
Mar
(12) |
Apr
(2) |
May
(10) |
Jun
(9) |
Jul
(10) |
Aug
(3) |
Sep
(1) |
Oct
(4) |
Nov
(6) |
Dec
|
| 2008 |
Jan
(7) |
Feb
(1) |
Mar
(5) |
Apr
(8) |
May
(6) |
Jun
|
Jul
(2) |
Aug
(29) |
Sep
(1) |
Oct
(3) |
Nov
(6) |
Dec
(113) |
| 2009 |
Jan
(7) |
Feb
(14) |
Mar
(38) |
Apr
(8) |
May
(2) |
Jun
(4) |
Jul
(1) |
Aug
(4) |
Sep
(11) |
Oct
(4) |
Nov
(15) |
Dec
(5) |
| 2010 |
Jan
(1) |
Feb
|
Mar
(5) |
Apr
(9) |
May
(5) |
Jun
|
Jul
(7) |
Aug
(1) |
Sep
(7) |
Oct
|
Nov
(2) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(3) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(25) |
Oct
(10) |
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
(2) |
Dec
(8) |
| 2013 |
Jan
|
Feb
(4) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: eric m. <mid...@gm...> - 2018-01-27 11:00:37
|
Hello,
Since I'm using a new version of the gnu compiler (g++ (Debian 6.3.0-18)
6.3.0 20170516) I'm getting these strange compiler errors related to the
LOKI_THREADS_ATOMIC_FUNCTIONS macro.
g++ -Wall -Werror -Wextra -fexceptions -ggdb -g3 -fPIC -std=gnu++14
-DLOKI_OBJECT_LEVEL_THREADING -I/home/eric/source/webserver/lib
-I/home/eric/source/generic/lib -I/home/eric/source/udev/lib
-I/usr/local/include/boost -I/usr/local/include/loki -I/usr/include
-I/home/eric/source/financedb/lib -I/usr/local/include/mariadb -c
/home/eric/source/webserver/lib/AppLib/Apps/AbstractApp.cpp -o
/home/eric/object/webserver/lib/AppLib/AbstractApp.o
In file included from /usr/include/loki/Singleton.h:22:0,
from
/home/eric/source/webserver/lib/ControllerLib/Controller.hpp:9,
from
/home/eric/source/webserver/lib/AppLib/Apps/AbstractApp.cpp:3:
/usr/include/loki/Threads.h: In static member function ‘static void
Loki::ObjectLevelLockable<Host, MutexPolicy>::AtomicAssign(volatile
IntType&, Loki::ObjectLevelLockable<Host, MutexPolicy>::IntType)’:
/usr/include/loki/Threads.h:505:9: error: return-statement with a value, in
function returning 'void' [-fpermissive]
LOKI_THREADS_ATOMIC_FUNCTIONS
There has been no change in my code since the time I used the previous
version of the compiler. Does anybody know what is causing these and why?
Kind regards
Eric
|
|
From: <and...@fr...> - 2017-02-03 13:02:02
|
Dear all, after more than a decade, I have reworked the 'loki.spec' file for more recent versions of 'rpmbuild' (version 4.12.0.1) and 'debbuild' (17.1.2). In addition, I created a set of patchfiles to suppress warnings issued by the GCC compiler (5.4.0). The results can be found in the Github project https://github.com/ascherer/loki-lib Cheers, Andreas --- Die Bundesliga hat begonnen! Alle Tore, alle Ergebnisse, alle News: Pocket Liga jetzt im https://app.adjust.com/dpynzd oder https://app.adjust.com/dpynzd herunterladen - kostenlos! |
|
From: Kamil S. <k.d...@gm...> - 2016-02-12 17:13:58
|
Index: test/LevelMutex/Thing.cpp
===================================================================
--- test/LevelMutex/Thing.cpp (revision 1191)
+++ test/LevelMutex/Thing.cpp (working copy)
@@ -601,7 +601,7 @@
// ----------------------------------------------------------------------------
-void SomeThing::SetValue( unsigned int value )
+void SomeThing::SetValue( uintptr_t value )
{
assert( NULL != this );
m_value = value; |
|
From: SourceForge.net <no...@so...> - 2013-03-07 09:01:51
|
Bugs item #3607146, was opened at 2013-03-07 01:01 Message generated for change (Tracker Item Submitted) made by hexcoder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3607146&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hexcoder (hexcoder) Assigned to: Nobody/Anonymous (nobody) Summary: patch: build loki-0.1.7 with MSVC 2010 Initial Comment: (Maybe this is a duplicate, I could not see anything inserted here from my first post...) With the following minimalistic patch, I was able to compile loki-0.1.7 and let the unit tests run. They passed 100%. Please consider for inclusion. Thanks for your work, Hexcoder ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3607146&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2013-02-28 11:38:54
|
Bugs item #3603408, was opened at 2013-02-05 03:17 Message generated for change (Comment added) made by kingduckz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3603408&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: King_DuckZ (kingduckz) Assigned to: Nobody/Anonymous (nobody) Summary: Broken build when exceptions are disabled Initial Comment: In dev-libs/ferrisloki version 3.0.3 installed from Portage the file Singleton.h doesn't build on EKOPath compiler when exceptions are disabled. In my case it produces the following error: In file included from /usr/include/FerrisLoki/loki/SmartPtr.h:33: In file included from /usr/include/FerrisLoki/loki/SmallObj.h:23: /usr/include/FerrisLoki/loki/Singleton.h:358:11: error: cannot use 'throw' with exceptions disabled { throw std::logic_error("Dead Reference Detected"); } My EKOPath version is: PathScale EKOPath(tm) Compiler Suite: Version 5.0.0 Built on: Thread model: posix GNU gcc compatible version 4.2.1 I would expect any throw in the code to be a macro or to be within an #ifdef. ---------------------------------------------------------------------- Comment By: King_DuckZ (kingduckz) Date: 2013-02-28 03:38 Message: Ok sorry for the previous comment, that's unrelated to this bug. That's what I get for drinking too much coffee and doing things hurriedly. ---------------------------------------------------------------------- Comment By: King_DuckZ (kingduckz) Date: 2013-02-28 03:36 Message: This also happens on gcc, sorry for not testing it earlier: /usr/include/FerrisLoki/loki/Functor.h: In static member function ‘static U* Loki::Private::FunctorImplBase<R, ThreadingModel>::Clone(U*)’: /usr/include/FerrisLoki/loki/Functor.h:93:17: error: cannot use typeid with -fno-rtti /usr/include/FerrisLoki/loki/Functor.h:93:17: error: cannot use typeid with -fno-rtti make[2]: *** [DuckLib/DuckUtils/CMakeFiles/DuckUtils.dir/ObjectLoader.cpp.o] Errore 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3603408&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2013-02-28 11:36:29
|
Bugs item #3603408, was opened at 2013-02-05 03:17 Message generated for change (Comment added) made by kingduckz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3603408&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: King_DuckZ (kingduckz) Assigned to: Nobody/Anonymous (nobody) Summary: Broken build when exceptions are disabled Initial Comment: In dev-libs/ferrisloki version 3.0.3 installed from Portage the file Singleton.h doesn't build on EKOPath compiler when exceptions are disabled. In my case it produces the following error: In file included from /usr/include/FerrisLoki/loki/SmartPtr.h:33: In file included from /usr/include/FerrisLoki/loki/SmallObj.h:23: /usr/include/FerrisLoki/loki/Singleton.h:358:11: error: cannot use 'throw' with exceptions disabled { throw std::logic_error("Dead Reference Detected"); } My EKOPath version is: PathScale EKOPath(tm) Compiler Suite: Version 5.0.0 Built on: Thread model: posix GNU gcc compatible version 4.2.1 I would expect any throw in the code to be a macro or to be within an #ifdef. ---------------------------------------------------------------------- Comment By: King_DuckZ (kingduckz) Date: 2013-02-28 03:36 Message: This also happens on gcc, sorry for not testing it earlier: /usr/include/FerrisLoki/loki/Functor.h: In static member function ‘static U* Loki::Private::FunctorImplBase<R, ThreadingModel>::Clone(U*)’: /usr/include/FerrisLoki/loki/Functor.h:93:17: error: cannot use typeid with -fno-rtti /usr/include/FerrisLoki/loki/Functor.h:93:17: error: cannot use typeid with -fno-rtti make[2]: *** [DuckLib/DuckUtils/CMakeFiles/DuckUtils.dir/ObjectLoader.cpp.o] Errore 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3603408&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2013-02-05 11:18:26
|
Bugs item #3603408, was opened at 2013-02-05 03:17 Message generated for change (Settings changed) made by kingduckz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3603408&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: King_DuckZ (kingduckz) Assigned to: Nobody/Anonymous (nobody) >Summary: Broken build when exceptions are disabled Initial Comment: In dev-libs/ferrisloki version 3.0.3 installed from Portage the file Singleton.h doesn't build on EKOPath compiler when exceptions are disabled. In my case it produces the following error: In file included from /usr/include/FerrisLoki/loki/SmartPtr.h:33: In file included from /usr/include/FerrisLoki/loki/SmallObj.h:23: /usr/include/FerrisLoki/loki/Singleton.h:358:11: error: cannot use 'throw' with exceptions disabled { throw std::logic_error("Dead Reference Detected"); } My EKOPath version is: PathScale EKOPath(tm) Compiler Suite: Version 5.0.0 Built on: Thread model: posix GNU gcc compatible version 4.2.1 I would expect any throw in the code to be a macro or to be within an #ifdef. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3603408&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2013-02-05 11:17:42
|
Bugs item #3603408, was opened at 2013-02-05 03:17 Message generated for change (Tracker Item Submitted) made by kingduckz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3603408&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: King_DuckZ (kingduckz) Assigned to: Nobody/Anonymous (nobody) Summary: Broken build when excteptions are disabled Initial Comment: In dev-libs/ferrisloki version 3.0.3 installed from Portage the file Singleton.h doesn't build on EKOPath compiler when exceptions are disabled. In my case it produces the following error: In file included from /usr/include/FerrisLoki/loki/SmartPtr.h:33: In file included from /usr/include/FerrisLoki/loki/SmallObj.h:23: /usr/include/FerrisLoki/loki/Singleton.h:358:11: error: cannot use 'throw' with exceptions disabled { throw std::logic_error("Dead Reference Detected"); } My EKOPath version is: PathScale EKOPath(tm) Compiler Suite: Version 5.0.0 Built on: Thread model: posix GNU gcc compatible version 4.2.1 I would expect any throw in the code to be a macro or to be within an #ifdef. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3603408&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2012-12-29 09:59:34
|
Bugs item #3598016, was opened at 2012-12-20 22:42 Message generated for change (Settings changed) made by vaneyli You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3598016&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None >Priority: 8 Private: No Submitted By: vaneyli (vaneyli) Assigned to: Nobody/Anonymous (nobody) Summary: Smallobject benchmark in qtcreator,ubuntu,notebook Initial Comment: output shows : the speed of the smallobject is much slower than the default, also the boost!!! why? please help me:) I've downloaded. the newest code . //part of output Allocator Benchmark Tests with 2 bytes big objects new = global new/delete sizeof(A) = 2 SmallObj = Loki::SmallObject sizeof(B) = 8 ValueObj = Loki::SmallValueObject sizeof(C) = 2 boost = boost::object_pool sizeof(D) = 2 allocator= std::allocator sizeof(A) = 2 malloc = std::malloc/free sizeof(A) = 2 1000000 times 'delete new T' new : seconds: 40 relative time: 100% speed-up factor: 1 SmallObj : seconds: 280 relative time: 700% speed-up factor: 0.14 ValueObj : seconds: 270 relative time: 675% speed-up factor: 0.15 boost : seconds: 50 relative time: 125% speed-up factor: 0.8 allocator: seconds: 60 relative time: 150% speed-up factor: 0.67 malloc : seconds: 40 relative time: 100% speed-up factor: 1 N=3 : 1000000 times 'delete[] new T[N]' new : seconds: 50 relative time: 100% speed-up factor: 1 SmallObj : seconds: 320 relative time: 640% speed-up factor: 0.16 ValueObj : seconds: 320 relative time: 640% speed-up factor: 0.16 boost : seconds: 50 relative time: 100% speed-up factor: 1 allocator: seconds: 60 relative time: 120% speed-up factor: 0.83 malloc : seconds: 40 relative time: 80% speed-up factor: 1.25 i=0...1000000 : 1. 'arr[i] = new T' 2. 'delete arr[i]' 1. new : seconds: 40 relative time: 100% speed-up factor: 1 2. new : seconds: 30 relative time: 100% speed-up factor: 1 1. SmallObj : seconds: 220 relative time: 550% speed-up factor: 0.18 2. SmallObj : seconds: 200 relative time: 667% speed-up factor: 0.15 1. ValueObj : seconds: 220 relative time: 550% speed-up factor: 0.18 2. ValueObj : seconds: 180 relative time: 600% speed-up factor: 0.17 1. boost : seconds: 30 relative time: 75% speed-up factor: 1.33 2. boost : boost::object_pool is not tested because it's too slow 1. allocator: seconds: 40 relative time: 100% speed-up factor: 1 2. allocator: seconds: 20 relative time: 67% speed-up factor: 1.5 1. malloc : seconds: 20 relative time: 50% speed-up factor: 2 2. malloc : seconds: 20 relative time: 67% speed-up factor: 1.5 ---------------------------------------------------------------------- Comment By: vaneyli (vaneyli) Date: 2012-12-29 01:58 Message: *Loki: Version 0.1.7 January 2009 *ubuntu c++ complier: g++ 4.4.5 *other: I'v found that the sgl stl v3.3 has adopted the same skill as the smallobject in the loki. But the stl in the c++ complier just use the default alloc. answer: the present malloc or operator new has been optimized . ???? help me:) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3598016&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2012-12-29 09:58:24
|
Bugs item #3598016, was opened at 2012-12-20 22:42 Message generated for change (Comment added) made by vaneyli You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3598016&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: vaneyli (vaneyli) Assigned to: Nobody/Anonymous (nobody) Summary: Smallobject benchmark in qtcreator,ubuntu,notebook Initial Comment: output shows : the speed of the smallobject is much slower than the default, also the boost!!! why? please help me:) I've downloaded. the newest code . //part of output Allocator Benchmark Tests with 2 bytes big objects new = global new/delete sizeof(A) = 2 SmallObj = Loki::SmallObject sizeof(B) = 8 ValueObj = Loki::SmallValueObject sizeof(C) = 2 boost = boost::object_pool sizeof(D) = 2 allocator= std::allocator sizeof(A) = 2 malloc = std::malloc/free sizeof(A) = 2 1000000 times 'delete new T' new : seconds: 40 relative time: 100% speed-up factor: 1 SmallObj : seconds: 280 relative time: 700% speed-up factor: 0.14 ValueObj : seconds: 270 relative time: 675% speed-up factor: 0.15 boost : seconds: 50 relative time: 125% speed-up factor: 0.8 allocator: seconds: 60 relative time: 150% speed-up factor: 0.67 malloc : seconds: 40 relative time: 100% speed-up factor: 1 N=3 : 1000000 times 'delete[] new T[N]' new : seconds: 50 relative time: 100% speed-up factor: 1 SmallObj : seconds: 320 relative time: 640% speed-up factor: 0.16 ValueObj : seconds: 320 relative time: 640% speed-up factor: 0.16 boost : seconds: 50 relative time: 100% speed-up factor: 1 allocator: seconds: 60 relative time: 120% speed-up factor: 0.83 malloc : seconds: 40 relative time: 80% speed-up factor: 1.25 i=0...1000000 : 1. 'arr[i] = new T' 2. 'delete arr[i]' 1. new : seconds: 40 relative time: 100% speed-up factor: 1 2. new : seconds: 30 relative time: 100% speed-up factor: 1 1. SmallObj : seconds: 220 relative time: 550% speed-up factor: 0.18 2. SmallObj : seconds: 200 relative time: 667% speed-up factor: 0.15 1. ValueObj : seconds: 220 relative time: 550% speed-up factor: 0.18 2. ValueObj : seconds: 180 relative time: 600% speed-up factor: 0.17 1. boost : seconds: 30 relative time: 75% speed-up factor: 1.33 2. boost : boost::object_pool is not tested because it's too slow 1. allocator: seconds: 40 relative time: 100% speed-up factor: 1 2. allocator: seconds: 20 relative time: 67% speed-up factor: 1.5 1. malloc : seconds: 20 relative time: 50% speed-up factor: 2 2. malloc : seconds: 20 relative time: 67% speed-up factor: 1.5 ---------------------------------------------------------------------- >Comment By: vaneyli (vaneyli) Date: 2012-12-29 01:58 Message: *Loki: Version 0.1.7 January 2009 *ubuntu c++ complier: g++ 4.4.5 *other: I'v found that the sgl stl v3.3 has adopted the same skill as the smallobject in the loki. But the stl in the c++ complier just use the default alloc. answer: the present malloc or operator new has been optimized . ???? help me:) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3598016&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2012-12-21 06:42:34
|
Bugs item #3598016, was opened at 2012-12-20 22:42 Message generated for change (Tracker Item Submitted) made by vaneyli You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3598016&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: vaneyli (vaneyli) Assigned to: Nobody/Anonymous (nobody) Summary: Smallobject benchmark in qtcreator,ubuntu,notebook Initial Comment: output shows : the speed of the smallobject is much slower than the default, also the boost!!! why? please help me:) I've downloaded. the newest code . //part of output Allocator Benchmark Tests with 2 bytes big objects new = global new/delete sizeof(A) = 2 SmallObj = Loki::SmallObject sizeof(B) = 8 ValueObj = Loki::SmallValueObject sizeof(C) = 2 boost = boost::object_pool sizeof(D) = 2 allocator= std::allocator sizeof(A) = 2 malloc = std::malloc/free sizeof(A) = 2 1000000 times 'delete new T' new : seconds: 40 relative time: 100% speed-up factor: 1 SmallObj : seconds: 280 relative time: 700% speed-up factor: 0.14 ValueObj : seconds: 270 relative time: 675% speed-up factor: 0.15 boost : seconds: 50 relative time: 125% speed-up factor: 0.8 allocator: seconds: 60 relative time: 150% speed-up factor: 0.67 malloc : seconds: 40 relative time: 100% speed-up factor: 1 N=3 : 1000000 times 'delete[] new T[N]' new : seconds: 50 relative time: 100% speed-up factor: 1 SmallObj : seconds: 320 relative time: 640% speed-up factor: 0.16 ValueObj : seconds: 320 relative time: 640% speed-up factor: 0.16 boost : seconds: 50 relative time: 100% speed-up factor: 1 allocator: seconds: 60 relative time: 120% speed-up factor: 0.83 malloc : seconds: 40 relative time: 80% speed-up factor: 1.25 i=0...1000000 : 1. 'arr[i] = new T' 2. 'delete arr[i]' 1. new : seconds: 40 relative time: 100% speed-up factor: 1 2. new : seconds: 30 relative time: 100% speed-up factor: 1 1. SmallObj : seconds: 220 relative time: 550% speed-up factor: 0.18 2. SmallObj : seconds: 200 relative time: 667% speed-up factor: 0.15 1. ValueObj : seconds: 220 relative time: 550% speed-up factor: 0.18 2. ValueObj : seconds: 180 relative time: 600% speed-up factor: 0.17 1. boost : seconds: 30 relative time: 75% speed-up factor: 1.33 2. boost : boost::object_pool is not tested because it's too slow 1. allocator: seconds: 40 relative time: 100% speed-up factor: 1 2. allocator: seconds: 20 relative time: 67% speed-up factor: 1.5 1. malloc : seconds: 20 relative time: 50% speed-up factor: 2 2. malloc : seconds: 20 relative time: 67% speed-up factor: 1.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3598016&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2012-12-03 13:59:33
|
Bugs item #3591349, was opened at 2012-11-30 05:45 Message generated for change (Comment added) made by tjapoeh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3591349&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 8 Private: No Submitted By: Frank Olthuis (tjapoeh) Assigned to: Nobody/Anonymous (nobody) Summary: ThreadingModel is largely ignored by AllocatorSingleton Initial Comment: One would expect allocations and deallocations to be guarded when either the ClassLevelLockable or ObjectLevelLockable policy is specified for an AllocatorSingleton. This is not the case though. A few functions are guarded, such as creation of the singleton and AllocatorSingleton is derived from SmallObjAllocator, which knows nothing whatsoever about threading models. This suggests that any mutex locking should be taken care of by AllocatorSingleton, which does know about the threading model. Alternatively, knowledge of locking could be moved to SmallObjAllocator. In both cases this would imply that the locking which is now done in SmallObject itself should be moved to its allocator. ---------------------------------------------------------------------- >Comment By: Frank Olthuis (tjapoeh) Date: 2012-12-03 05:59 Message: Ah, it turns out I had forgotten to remove a change I had made locally in Loki's Mutex class. After removing those changes the CriticalSection performs better than CMutex, as was to be expected. Conclusion: The problem is solved by adding mutex locks to LokiAllocator::Allocate en LokiAllocator::Deallocate. ---------------------------------------------------------------------- Comment By: Frank Olthuis (tjapoeh) Date: 2012-12-03 05:46 Message: The solution to add mutex locks to LokiAllocator::Allocate en Deallocate actually turns out quite ok if I replace Loki's default Mutex (which on Windows is a CriticalSection) by a CMutex. Although the performance is about 50% of that without the lock, at least it's now functioning correctly. ---------------------------------------------------------------------- Comment By: Frank Olthuis (tjapoeh) Date: 2012-12-03 02:38 Message: I seem to be able to work around the problem by adding mutex locks to LokiAllocator::Allocate() and LokiAllocator::Deallocate(). Unfortunately, this is devastating for the performance of the allocator. I guess the better solutions is not to use AllocatorSingleton, but to create a new allocator instance for each LokiAllocator. This should only be necessary in a multi-threaded model. ---------------------------------------------------------------------- Comment By: Frank Olthuis (tjapoeh) Date: 2012-12-03 02:22 Message: This seem a critical bug to me. The problem becomes very clear once you use a LokiAllocator in two different threads. The problem is that it makes use of AllocatorSingleton, so this is the same instance in the two threads, at least if the chunk sizes are identical. Allocations or deallocations from different threads are thus handled by the same allocator without doing any locking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3591349&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2012-12-03 13:46:06
|
Bugs item #3591349, was opened at 2012-11-30 05:45 Message generated for change (Comment added) made by tjapoeh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3591349&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 8 Private: No Submitted By: Frank Olthuis (tjapoeh) Assigned to: Nobody/Anonymous (nobody) Summary: ThreadingModel is largely ignored by AllocatorSingleton Initial Comment: One would expect allocations and deallocations to be guarded when either the ClassLevelLockable or ObjectLevelLockable policy is specified for an AllocatorSingleton. This is not the case though. A few functions are guarded, such as creation of the singleton and AllocatorSingleton is derived from SmallObjAllocator, which knows nothing whatsoever about threading models. This suggests that any mutex locking should be taken care of by AllocatorSingleton, which does know about the threading model. Alternatively, knowledge of locking could be moved to SmallObjAllocator. In both cases this would imply that the locking which is now done in SmallObject itself should be moved to its allocator. ---------------------------------------------------------------------- >Comment By: Frank Olthuis (tjapoeh) Date: 2012-12-03 05:46 Message: The solution to add mutex locks to LokiAllocator::Allocate en Deallocate actually turns out quite ok if I replace Loki's default Mutex (which on Windows is a CriticalSection) by a CMutex. Although the performance is about 50% of that without the lock, at least it's now functioning correctly. ---------------------------------------------------------------------- Comment By: Frank Olthuis (tjapoeh) Date: 2012-12-03 02:38 Message: I seem to be able to work around the problem by adding mutex locks to LokiAllocator::Allocate() and LokiAllocator::Deallocate(). Unfortunately, this is devastating for the performance of the allocator. I guess the better solutions is not to use AllocatorSingleton, but to create a new allocator instance for each LokiAllocator. This should only be necessary in a multi-threaded model. ---------------------------------------------------------------------- Comment By: Frank Olthuis (tjapoeh) Date: 2012-12-03 02:22 Message: This seem a critical bug to me. The problem becomes very clear once you use a LokiAllocator in two different threads. The problem is that it makes use of AllocatorSingleton, so this is the same instance in the two threads, at least if the chunk sizes are identical. Allocations or deallocations from different threads are thus handled by the same allocator without doing any locking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3591349&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2012-12-03 10:38:24
|
Bugs item #3591349, was opened at 2012-11-30 05:45 Message generated for change (Comment added) made by tjapoeh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3591349&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 8 Private: No Submitted By: Frank Olthuis (tjapoeh) Assigned to: Nobody/Anonymous (nobody) Summary: ThreadingModel is largely ignored by AllocatorSingleton Initial Comment: One would expect allocations and deallocations to be guarded when either the ClassLevelLockable or ObjectLevelLockable policy is specified for an AllocatorSingleton. This is not the case though. A few functions are guarded, such as creation of the singleton and AllocatorSingleton is derived from SmallObjAllocator, which knows nothing whatsoever about threading models. This suggests that any mutex locking should be taken care of by AllocatorSingleton, which does know about the threading model. Alternatively, knowledge of locking could be moved to SmallObjAllocator. In both cases this would imply that the locking which is now done in SmallObject itself should be moved to its allocator. ---------------------------------------------------------------------- >Comment By: Frank Olthuis (tjapoeh) Date: 2012-12-03 02:38 Message: I seem to be able to work around the problem by adding mutex locks to LokiAllocator::Allocate() and LokiAllocator::Deallocate(). Unfortunately, this is devastating for the performance of the allocator. I guess the better solutions is not to use AllocatorSingleton, but to create a new allocator instance for each LokiAllocator. This should only be necessary in a multi-threaded model. ---------------------------------------------------------------------- Comment By: Frank Olthuis (tjapoeh) Date: 2012-12-03 02:22 Message: This seem a critical bug to me. The problem becomes very clear once you use a LokiAllocator in two different threads. The problem is that it makes use of AllocatorSingleton, so this is the same instance in the two threads, at least if the chunk sizes are identical. Allocations or deallocations from different threads are thus handled by the same allocator without doing any locking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3591349&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2012-12-03 10:22:26
|
Bugs item #3591349, was opened at 2012-11-30 05:45 Message generated for change (Comment added) made by tjapoeh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3591349&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None >Priority: 8 Private: No Submitted By: Frank Olthuis (tjapoeh) Assigned to: Nobody/Anonymous (nobody) Summary: ThreadingModel is largely ignored by AllocatorSingleton Initial Comment: One would expect allocations and deallocations to be guarded when either the ClassLevelLockable or ObjectLevelLockable policy is specified for an AllocatorSingleton. This is not the case though. A few functions are guarded, such as creation of the singleton and AllocatorSingleton is derived from SmallObjAllocator, which knows nothing whatsoever about threading models. This suggests that any mutex locking should be taken care of by AllocatorSingleton, which does know about the threading model. Alternatively, knowledge of locking could be moved to SmallObjAllocator. In both cases this would imply that the locking which is now done in SmallObject itself should be moved to its allocator. ---------------------------------------------------------------------- >Comment By: Frank Olthuis (tjapoeh) Date: 2012-12-03 02:22 Message: This seem a critical bug to me. The problem becomes very clear once you use a LokiAllocator in two different threads. The problem is that it makes use of AllocatorSingleton, so this is the same instance in the two threads, at least if the chunk sizes are identical. Allocations or deallocations from different threads are thus handled by the same allocator without doing any locking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3591349&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2012-12-02 01:32:09
|
Bugs item #3591332, was opened at 2012-11-30 04:53 Message generated for change (Comment added) made by tjapoeh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3591332&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Frank Olthuis (tjapoeh) Assigned to: Nobody/Anonymous (nobody) Summary: Loki::Mutex has no effect on Windows Initial Comment: Loki's locking paradigm expect locking and unlocking to take place by way of the oneliner <code> typename MyThreadingModel::Lock lock; </code> This requires locking to take place in the mutex's contructor, and unlocking in its destructor. On Windows though, Loki's default Mutex class makes use of a CRITICAL_SECTION, which is only created and destroyed in the contructor and destructor respectively. Neither EnterCriticalSection nor LeaveCriticalSection are called. In my view, the constructor and destructor should be as follows: Mutex() LOKI_THREADS_MUTEX_CTOR(mtx_) { LOKI_THREADS_MUTEX_INIT(&mtx_); LOKI_THREADS_MUTEX_LOCK(&mtx_); } ~Mutex() { LOKI_THREADS_MUTEX_UNLOCK(&mtx_); LOKI_THREADS_MUTEX_DELETE(&mtx_); } ---------------------------------------------------------------------- >Comment By: Frank Olthuis (tjapoeh) Date: 2012-12-01 17:32 Message: Ah, dealing with race conditinos can make your mind fuzzy, apparently. Of course the locking is done by the Lock class of the threading policy. ---------------------------------------------------------------------- Comment By: Frank Olthuis (tjapoeh) Date: 2012-12-01 17:32 Message: This problem is not a bug within the Loki library. It is something that is wrong with the compiler or other libraries you are using. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3591332&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2012-11-30 13:45:32
|
Bugs item #3591349, was opened at 2012-11-30 05:45 Message generated for change (Tracker Item Submitted) made by tjapoeh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3591349&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Frank Olthuis (tjapoeh) Assigned to: Nobody/Anonymous (nobody) Summary: ThreadingModel is largely ignored by AllocatorSingleton Initial Comment: One would expect allocations and deallocations to be guarded when either the ClassLevelLockable or ObjectLevelLockable policy is specified for an AllocatorSingleton. This is not the case though. A few functions are guarded, such as creation of the singleton and AllocatorSingleton is derived from SmallObjAllocator, which knows nothing whatsoever about threading models. This suggests that any mutex locking should be taken care of by AllocatorSingleton, which does know about the threading model. Alternatively, knowledge of locking could be moved to SmallObjAllocator. In both cases this would imply that the locking which is now done in SmallObject itself should be moved to its allocator. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3591349&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2012-11-30 12:53:19
|
Bugs item #3591332, was opened at 2012-11-30 04:53 Message generated for change (Tracker Item Submitted) made by tjapoeh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3591332&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Frank Olthuis (tjapoeh) Assigned to: Nobody/Anonymous (nobody) Summary: Loki::Mutex has no effect on Windows Initial Comment: Loki's locking paradigm expect locking and unlocking to take place by way of the oneliner <code> typename MyThreadingModel::Lock lock; </code> This requires locking to take place in the mutex's contructor, and unlocking in its destructor. On Windows though, Loki's default Mutex class makes use of a CRITICAL_SECTION, which is only created and destroyed in the contructor and destructor respectively. Neither EnterCriticalSection nor LeaveCriticalSection are called. In my view, the constructor and destructor should be as follows: Mutex() LOKI_THREADS_MUTEX_CTOR(mtx_) { LOKI_THREADS_MUTEX_INIT(&mtx_); LOKI_THREADS_MUTEX_LOCK(&mtx_); } ~Mutex() { LOKI_THREADS_MUTEX_UNLOCK(&mtx_); LOKI_THREADS_MUTEX_DELETE(&mtx_); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3591332&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2012-08-13 21:18:41
|
Patches item #3557029, was opened at 2012-08-13 14:18 Message generated for change (Tracker Item Submitted) made by rpavlik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396646&aid=3557029&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Pavlik (rpavlik) Assigned to: Nobody/Anonymous (nobody) Summary: Type-related cleanup on 64-bit linux Initial Comment: Some more int type cleanups - mostly warning fixes, IIRC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396646&aid=3557029&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2012-08-13 21:16:49
|
Patches item #3557027, was opened at 2012-08-13 14:16 Message generated for change (Tracker Item Submitted) made by rpavlik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396646&aid=3557027&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Pavlik (rpavlik) Assigned to: Nobody/Anonymous (nobody) Summary: Type-related build errors in tests on 64-bit Initial Comment: These patches aren't perfect (a windows msvc 64-bit build will fail, I think) but that fix is easy. This replaces a lot of "unsigned int" with "uintptr_t" to build on gcc 4.5 on Linux 64-bit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396646&aid=3557027&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2012-04-23 10:06:57
|
Bugs item #3520583, was opened at 2012-04-23 03:06 Message generated for change (Tracker Item Submitted) made by wizardhobo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3520583&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wizard Hobo (wizardhobo) Assigned to: Nobody/Anonymous (nobody) Summary: yasli::vector::insert fails if reserve reallocates memory Initial Comment: // $Id: yasli_vector.h 754 2006-10-17 19:59:11Z syntheticpp $ The implementation for yasli::vector::insert (line 402) uses the position parameter _after_ a call to reserve. But if the call to reserve resulted in a memory reallocation, this iterator has become invalid. Consequently, 'pos' on line 406 is incorrect and the insert call in line 407 also does "the wrong thing"TM. The solution is to calculate pos _before_ the reserve call and recalculate position from that _after_ the reserve call. const size_type pos = position - begin(); reserve(size() + 1); position = begin() + pos; insert(position, (size_type)1, x); return ebo_.beg_ + pos; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3520583&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2012-04-02 06:02:57
|
Bugs item #3509427, was opened at 2012-03-20 10:01 Message generated for change (Comment added) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3509427&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: King_DuckZ (kingduckz) >Assigned to: Richard Sposato (rich_sposato) Summary: Broken build on Visual Studio Initial Comment: Version 1177 on trunk doesn't build on VS 2005/2008. The problem is in a template method being instantiated with a reference as its template type T. The function then takes a T& argument, that results in a reference to a reference. In C++99 this is forbidden (cf. Standard §8.3.4). My solution was to use TypeTraits::ParameterType, but this has a couple disadvantages: 1) a dependency to TypeTraits.h in SafeFormat.h is added 2) automatic template deduction won't work anymore At least problem 1 could be solved by writing a "small" replacement for TypeTraits::ParameterType, which can be put in a leaf .h and reused elsewhere (that's a very low level feature IMO to carry any dependency). Unfortunately I couldn't spend too much time on the code, so maybe there's a better solution I don't see. ---------------------------------------------------------------------- >Comment By: Richard Sposato (rich_sposato) Date: 2012-04-01 23:02 Message: Fixed in revision 1179. Added use of Loki::TypeTraits. ---------------------------------------------------------------------- Comment By: King_DuckZ (kingduckz) Date: 2012-03-20 10:06 Message: Apparently the problem was introduced at revision 1160 "Added functions that print directly to cout" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3509427&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2012-03-20 17:07:00
|
Bugs item #3509427, was opened at 2012-03-20 10:01 Message generated for change (Comment added) made by kingduckz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3509427&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: King_DuckZ (kingduckz) Assigned to: Nobody/Anonymous (nobody) Summary: Broken build on Visual Studio Initial Comment: Version 1177 on trunk doesn't build on VS 2005/2008. The problem is in a template method being instantiated with a reference as its template type T. The function then takes a T& argument, that results in a reference to a reference. In C++99 this is forbidden (cf. Standard §8.3.4). My solution was to use TypeTraits::ParameterType, but this has a couple disadvantages: 1) a dependency to TypeTraits.h in SafeFormat.h is added 2) automatic template deduction won't work anymore At least problem 1 could be solved by writing a "small" replacement for TypeTraits::ParameterType, which can be put in a leaf .h and reused elsewhere (that's a very low level feature IMO to carry any dependency). Unfortunately I couldn't spend too much time on the code, so maybe there's a better solution I don't see. ---------------------------------------------------------------------- >Comment By: King_DuckZ (kingduckz) Date: 2012-03-20 10:06 Message: Apparently the problem was introduced at revision 1160 "Added functions that print directly to cout" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3509427&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2012-03-20 17:01:46
|
Bugs item #3509427, was opened at 2012-03-20 10:01 Message generated for change (Tracker Item Submitted) made by kingduckz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3509427&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: King_DuckZ (kingduckz) Assigned to: Nobody/Anonymous (nobody) Summary: Broken build on Visual Studio Initial Comment: Version 1177 on trunk doesn't build on VS 2005/2008. The problem is in a template method being instantiated with a reference as its template type T. The function then takes a T& argument, that results in a reference to a reference. In C++99 this is forbidden (cf. Standard §8.3.4). My solution was to use TypeTraits::ParameterType, but this has a couple disadvantages: 1) a dependency to TypeTraits.h in SafeFormat.h is added 2) automatic template deduction won't work anymore At least problem 1 could be solved by writing a "small" replacement for TypeTraits::ParameterType, which can be put in a leaf .h and reused elsewhere (that's a very low level feature IMO to carry any dependency). Unfortunately I couldn't spend too much time on the code, so maybe there's a better solution I don't see. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=3509427&group_id=29557 |
|
From: SourceForge.net <no...@so...> - 2011-10-26 00:16:25
|
Bugs item #1408845, was opened at 2006-01-18 00:50 Message generated for change (Comment added) made by rich_sposato You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=1408845&group_id=29557 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open >Resolution: Accepted Priority: 7 Private: No Submitted By: Steven Barbaglia (stevenuk) >Assigned to: Richard Sposato (rich_sposato) Summary: Race condition in RefCountedMTAdj::Release Initial Comment: Consider the following usage example: MySmartPtr shared; // both writer and reader can access this smart pointer // Writer thread MySmartPtr update(new MyObj); // new referenced object shared = update; // shared smart pointer updated // Reader thread MySmartPtr read(shared); // shared pointer copied to reserve referenced object // access object through smart pointer The referenced object is never updated once it is wrapped in a smart pointer, but the shared smart pointer is. The reader takes a local copy of the shared smart pointer in the expectation that thereafter it can access the referenced object. Should the writer thread update the shared object again (by assignment with a smart pointer referencing a new object), the local smart pointer in the reader will still be holding onto the old referenced object. This means that the writer and reader threads only potentially contend during the assignment in the writer and the copy-construction in the reader. At other times the reader and writer can work at their own pace: for example, the writer might be very fast and update the shared pointer often, whilst the reader might save to database the occasionally-retrieved snapshot. Can the reader thread rely on the smart pointer handling itself in a thread-safe way? My contention is that there is a race condition not addressed in RefCountedMT. Consider the following code extract from the Loki library: template <template <class> class ThreadingModel> struct RefCountedMTAdj { //... bool Release(const P&) { if (!ThreadingModel<RefCountedMT>:: AtomicDecrement(*pCount_)) { SmallObject<ThreadingModel>:: operator delete( const_cast<CountType *>(pCount_), sizeof(*pCount_)); return true; } return false; } //... } There is nothing to prevent the writer thread from being interupted once the AtomicDecrement operation has been completed, but before the delete operation (ie, counter has reached zero). Imagine the reader in my example takes its local copy of the shared smart pointer precisely at that moment. The code for both the copy constructor the the cloning method suggest the operation will complete and the reference counter will be incremented (ie, counter back to one). Once the writer thread wakes up and completes the delete operation, the smart pointer in the reader will be holding a dangling pointer. Furthermore, the Release method will return 'true', causing the deletion of the referenced object. The reader might be in the middle of accessing the refenrenced object through its local smart pointer... ops... As it stands, simultaneous reads and writes to smart pointers can have unpredicable results (as in example above). This limitation should be either documented or removed with an enhancement to the code. ---------------------------------------------------------------------- >Comment By: Richard Sposato (rich_sposato) Date: 2011-10-25 17:16 Message: I might be able to fix this bug by using GCC's atomic operation functions - or with InterlockedIncrement and InterlockedDecrement on Visual-Studio. Reopening bug and assigning to myself for further study. ---------------------------------------------------------------------- Comment By: Richard Sposato (rich_sposato) Date: 2007-04-27 16:38 Message: Logged In: YES user_id=749922 Originator: NO Hi Folks, I asked on comp.lang.c++.moderated if anybody had recommendations for how to fix this bug. http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/93c6579e620a40fa/be06b51a7bccb6bb?hl=en#be06b51a7bccb6bb I did not see any good recommendations. My conclusion is that no change to Loki's SmartPtr can fix this bug. There is no thread-safe way to write copy-constructor that works while the copied object's destructor is active in another thread. Even if we could modify the copy-ctor and dtor so they run okay in most situations, that won't fix the situation where the source object is completely destroyed in one thread before the copy-constructor even begins in another thread. Indeed, the fact that one object is trying to copy another while that other object is being destroyed indicates a higher-level design problem. I reluctantly recommend we close this bug as "Won't Fix". We can document this issue with a note in the SmartPtr header file. Cheers, Rich ---------------------------------------------------------------------- Comment By: Andreas Kunit (segelohr) Date: 2006-07-14 04:04 Message: Logged In: YES user_id=1555499 I don't see a race condition. Hypothesis: The copy constructor is called right before the delete operation of the smart pointer is called. Proof by contradiction: 1. When the delete operation is to call, there's only one smart pointer pointing to the pointee. 2. The one and only smart pointer must be the base for any copy operation. 3. When the delete operation is to call, the one and only smart pointer leaves his scope of validity. 4. When the smart pointer leaves his scope of validity, it may not be the base for a copy operation anymore. 5. No copy constructor may be called right before the delete operation. ------------------------------------------------- The other remark in the text is that smart pointers don't feature a synchronisation mechanism. IMO they don't have to. There are other patterns which cover this concern better. ---------------------------------------------------------------------- Comment By: Peter Kuemmel (syntheticpp) Date: 2006-05-30 07:32 Message: Logged In: YES user_id=1159765 Modified Files: SmartPtr.h Log Message: add warning about mt bug Index: SmartPtr.h =================================================================== RCS file: /cvsroot/loki-lib/loki/include/loki/SmartPtr.h,v retrieving revision 1.30 retrieving revision 1.31 diff -u -d -r1.30 -r1.31 --- SmartPtr.h 17 May 2006 16:04:32 -0000 1.30 +++ SmartPtr.h 30 May 2006 14:30:19 -0000 1.31 @@ -305,6 +305,10 @@ /// Implementation of the OwnershipPolicy used by SmartPtr /// Implements external reference counting for multithreaded programs /// Policy Usage: RefCountedMTAdj<ThreadingModel>::RefCountedMT +/// +/// \par Warning +/// There could be a race condition, see bug "Race condition in RefCountedMTAdj::Release" +/// http://sourceforge.net/tracker/index.php?func=detail&aid=1408845&group_id=29557&atid=396644 //////////////////////////////////////////////////////////////////////////////// template <template <class, class> class ThreadingModel, @@ -1521,6 +1525,9 @@ ---------------------------------------------------------------------- Comment By: Steven Barbaglia (stevenuk) Date: 2006-04-20 09:20 Message: Logged In: YES user_id=1420849 some more observations... some re-iteration of Peter's comments using different words to elicit fresh ideas... a bit negative only because of my inability to see a solution at present... 1) There is still no warning in the documentation that SmartPtr does not support simultaneous read and writes (ie, there will be impredictable results in changing what an instance of SmartPtr is pointing to when the said instance is accessabile by other threads) 2) Can a volatile resource (eg, the counter in RefCountedMT) be used to synchronise distinct instances? Isn't there a contraddiction here? Is this the theoretical principle that was breached? 3) The race condition on the writer side extends from the decision to delete the counter, through the deletion of the counter and referenced object and finally to the assignment of the new counter and referenced object. The reader should not be allowed to get hold of the pointers to the doomed counter and doomed referenced object. Currently, this 'transaction' is covered by distinct methods in RefCountedMT (as illustrated by Peter's example code), so I do not see how synchronisation can be achieved within the class. 4) Object-level synchronisation is not an option, since multiple instances are involved. A class level synchronisation object is a heavy-handed solution and could be a bottleneck. Could a fallback position be for the reader to be able to detect that it now holds dangling pointers? Maybe throw an exception? ---------------------------------------------------------------------- Comment By: Peter Kuemmel (syntheticpp) Date: 2006-02-28 08:03 Message: Logged In: YES user_id=1159765 /* Hi Rich, I can't see atomic-member-function-calls-only eliminates the problem. To demonstrate this I've written a "byte code" simulation of the problem, and it seems to me that atomic calls can't avoid the order in void bug(). */ // storage policy: double *ptr; void del(bool del) { if(del) delete ptr; } // essence of RefCountedMT int* pcount; struct Ref { void ctor(int* rhs) { pCount = rhs; } void clone() { ++*pCount; } bool Release() { --*pCount; return *pCount==0; } private: int* pCount; }; Ref t1; // thread 1 Ref t2; // thread 2 bool ok1; bool ok2; void init() { // both smart pointers have somewhere the pure pointer ptr = new double; // init counter pcount = new int; *pcount = 0; // t1 already points to ptr t1.ctor(pcount); t1.clone(); } void bug() { // this is the faulty order // t1 releases and t2 gets a copy // all calls correspond to atomic member function calls!! t2.ctor(pcount); ok1 = t1.Release(); t2.clone(); del(ok1); // t2 releases ok2 = t2.Release(); del(ok2); } int main() { init(); bug(); return 0; } ---------------------------------------------------------------------- Comment By: Richard Sposato (rich_sposato) Date: 2006-02-07 17:39 Message: Logged In: YES user_id=749922 We might be able to use a trick from the SmallObj.h file to solve this. What if the code was changed to something like: template <template <class> class ThreadingModel> struct RefCountedMTAdj { typedef ThreadingModel< RefCountedMT, MutexPolicy > MyLockingModel; //... bool Release(const P&) { typename MyLockingModel::Lock lock; (void)lock; --*pCount; if (!*pCount_)) { SmallObject<ThreadingModel>::operator delete( const_cast<CountType *>(pCount_), sizeof(*pCount_)); return true; } return false; } //... } The MyLockingModel::Lock object will keep the SmartPtr locked for the entire body of the function. Once locked, the count can be decremented directly without resorting to the AtomicDecrement function. When the function returns, the lock on the count is automatically released. ---------------------------------------------------------------------- Comment By: Peter Kuemmel (syntheticpp) Date: 2006-01-19 03:34 Message: Logged In: YES user_id=1159765 Any ideas for a fix? Here a first step: A fix should avoid that Release deletes pCount_ and returns true when "at the same time" the use of the copy constructor starts. So there must be a synchronization between RefCountedMT(const RefCountedMT& rhs) and bool Release(const P&) Incrementing *pCount_ in the ctor is not sufficient, I think. Also locking with ThreadingModel<RefCountedMT>::Lock does not avoid some cases where *pCount is decremented before the constructor it increments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=396644&aid=1408845&group_id=29557 |
73 messages has been excluded from this view by a project administrator.
