[Bug libstdc++/20979] __gnu_cxx::bitmap_allocator export pruning
--- Additional Comments From dhruvbird at yahoo dot com 2005-04-13 12:11 --- (In reply to comment #1) > Created an attachment (id=8615) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8615&action=view) > free_list:: static removal > Hi, What has been done seems ok, but there is just one thing that niggles me. There is now the _M_get_mutex() function, which itself is not thread safe. So, if 2 or more threads try to get memory simultaneously, then the _M_get_mutex() function will be called 2 times, and the mutex will be initialized 2 times If that is possible that is. Basically, there seems to be arace here. HOwever, with the previous scenario, the static was initialized before anything happned [I think]. -Dhruv. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20979
[Bug c++/13684] local static object variable constructed once but ctors and dtors called multiple times on same memory when called in multiple threads
--- Additional Comments From dhruvbird at yahoo dot com 2005-04-13 16:56 --- (In reply to comment #19) > I want to emphasize here again one principle of C and C++: Trust the > programmers, and allow them to do low-level tunings for performance. Or what > is > the purpose of C++ (when compared with "high-level" languages like Python)? > This "fix" rid the programmers of their right to choose the way they want. > > Unless the future C++ standard demands protection in such cases, I do not > think > the compiler-provided mechanism a good idea. I would agree with you. Btw, what is the approach adopted in case the app. is a single threaded one? Are the locks still taken in this case? Also, if it is an mt-app. but the programmer is sure that that particula function will NOT be reentrant, why should he pay the penalty of a lock or/and a check every time the function is called? Stroustrup continuously emphasised that C++ was designed to be as fast if not faster than C in most respects, and I guess that's why C++ is gaining popularity. If it were to use the java approach then it would be just another bloat-language -Dhruv. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13684
[Bug libstdc++/20979] __gnu_cxx::bitmap_allocator export pruning
--- Additional Comments From dhruvbird at yahoo dot com 2005-04-13 17:02
---
Subject: Re: __gnu_cxx::bitmap_allocator export pruning
--- bkoz at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
> --- Additional Comments From bkoz at gcc dot gnu
> dot org 2005-04-13 16:32 ---
> I posit that this usage of static local variables,
> as written, is thread safe
> with gcc-4.0.x compilers. (Since resolution of
> c++/13684).
>
> ! _Mutex*
> ! _M_get_mutex()
> ! {
> ! static _Mutex _S_mutex;
> ! return &_S_mutex;
> ! }
>
> This object is only constructed (and initialized)
> once. After initial
> construction, a pointer to the initial object is
> returned. Don't let the
> simplicity of this solution fool you!
>
> This change actually improves portability for
> initialization, especially on
> non-SVR4 platforms, where order of initalization of
> static objects may differ
> from expectations.
hmmm. then the code should be correct
However, wrt efficiency, there will be a penalty
beause you need to acquire a mutex to acquire a mutex!
Ironical isn't it
wrt initialization order, yes, this is definitely an
improvement.
Just as a thought, I was wondering if it could be made
global at the namespace level. then, all this wouldn't
matter, and initialization orders would also be
guaranteed
OT: WRT the static initialization problem.
Also, to make the check on whether guard has been
set/reset, a lock must be prepended before it right?
So, that would stall the bus for some time
Probably not what one would wish for ideally, but I'm
generally against the language protecting against
these kind of things.
>
> -benjamin
>
>
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20979
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching
> someone who is.
>
-Dhruv Matani
http://www.geocities.com/dhruvbird/
__
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20979
[Bug c++/19941] New: No warning emitted for nested switch statements.
When there are many nested switch statements, then the compiler does not
recognize bogus labels such as spelling mistakes like 'delault' instead of
'default', and goes on to generate code. Even with -Wall, no warning is
generated. However these stupidities(spelling mistakes) are recognized and
warnings to that effect are emitted in programs such as these:
#include
int
main()
{
int r = rand();
int s = 0;
switch (s)
{
case 0:
switch(r)
{
case 1:
s = 2;
break;
case 2:
s = 7;
break;
defauft:
s = 9;
}
default:
r = 9;
}
}
swtest.cpp: In function `int main()':
swtest.cpp:21: warning: label `defauft' defined but not used
-Dhruv.
--
Summary: No warning emitted for nested switch statements.
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dhruvbird at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19941
[Bug c++/19941] No warning emitted for nested switch statements.
--- Additional Comments From dhruvbird at yahoo dot com 2005-02-13 18:40 --- Created an attachment (id=8190) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8190&action=view) The files required for reproducing the bug, and a short description. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19941
[Bug c++/19941] No warning emitted for nested switch statements.
--- Additional Comments From dhruvbird at yahoo dot com 2005-02-13 18:44 --- (In reply to comment #1) > Created an attachment (id=8190) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8190&action=view) > The files required for reproducing the bug, and a short description. > Actually, it is not the spelling mistake that is recognized, but the lack of any control reaching that part of the code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19941
