--- Additional Comments From davids at webmaster dot com 2005-02-24 23:45
---
> The difference is that almost all uses of strchr are done on data
> which is not shared between threads, while many static local
> initializers are used on objects which are accessed from multiple
> threads (
--- Additional Comments From qrczak at knm dot org dot pl 2005-02-24 22:37
---
> By your definition of MT-safe, almost no function is MT-safe. Is 'strchr'
> MT-safe if you call it on a string while another function might modify that
> string? No, so lets put automatic locks around 'strch
--- Additional Comments From davids at webmaster dot com 2005-02-24 22:22
---
> They are non-portable no matter how static initializers are done:
> C++ doesn't include threads and POSIX doesn't include C++.
That's a bogus argument. There are no conflicts between the two standards.
> T
--- Additional Comments From qrczak at knm dot org dot pl 2005-02-24 21:06
---
> First, if we're talking about pthreads programs, which is the only case I'm
> suggesting removing the locking for, then those programs are already broken.
They are non-portable no matter how static initiali
--- Additional Comments From davids at webmaster dot com 2005-02-24 20:42
---
>The only thing which would change when you remove the automatically
>inserted locking is that some programs which used to work are now
>broken, and that some other programs which used to deadlock now
>invoke u
--- Additional Comments From qrczak at knm dot org dot pl 2005-02-24 17:31
---
> "multithreading is defined by an application design that ALLOWS FOR concurrent
> or simultaneous execution"
Initializers of static locals cannot execute concurrently, no matter whether
they are automaticall
--- Additional Comments From gniccolai at yahoo dot com 2005-02-24 16:04
---
(In reply to comment #20)
>
Sorry, the correct citation is:
"multithreading is defined by an application design that ALLOWS FOR concurrent
or simultaneous execution"
The rest is cited from Sergey P. Derev
--- Additional Comments From gniccolai at yahoo dot com 2005-02-24 11:00
---
(In reply to comment #18)
> I think this is a waste really for this bug to be open as non of the GCC
people commented on it and
> when the orginal bug was filed, there was a huge opportunity to talk over this
a
--- Additional Comments From davids at webmaster dot com 2005-02-23 02:19
---
> It's not the question of optimization but correctness.
Exactly, and not locking objects that may be modified from another thread is
not correct. Only the programmer knows whether an object may be modified
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
02:00 ---
I think this is a waste really for this bug to be open as non of the GCC people
commented on it and
when the orginal bug was filed, there was a huge opportunity to talk over this
and nothing was done.
So
--- Additional Comments From qrczak at knm dot org dot pl 2005-02-23 01:53
---
> The '-pthreads' flag should imply '-fno-threadsafe-statics'. For every other
> similar flag I can find, the default is to permit the compiler to make the
> optimizations that standard allows and specific fla
--- Additional Comments From davids at webmaster dot com 2005-02-23 01:30
---
The '-pthreads' flag should imply '-fno-threadsafe-statics'. For every other
similar flag I can find, the default is to permit the compiler to make the
optimizations that standard allows and specific flags are
--- Additional Comments From gniccolai at yahoo dot com 2005-02-22 10:27
---
>
> You say a hypothetical multithreaded C++ should state this as the semantics
> for
> static locals, and I don't disagree with you, provided we are not talking
> about
> one based on POSIX threads. POSIX sp
--- Additional Comments From davids at webmaster dot com 2005-02-20 23:59
---
What you keep ignoring is that the POSIX standard explicitly declares it a bug
to access data in one thread while it may be modified in another. It's not
"unfortunate timing", it's failure to use the proper co
--- Additional Comments From gniccolai at yahoo dot com 2005-02-20 23:36
---
This comment is relevant regarding the C++ ABI closure on which this idea has
been derived:
http://groups.google.it/groups?q=g:thl3050439784d&dq=&hl=it&lr=&client=firefox-a&rls=org.mozilla:it-IT:official_s&selm
--- Additional Comments From qrczak at knm dot org dot pl 2005-02-20 21:43
---
> >Static locals in C++ are an equivalent to pthread_once in C/POSIX.
>
> Even in the single-threaded case, C++ leaves it undefined what happens if you
> reenter a function that invokes a static initializer f
--- Additional Comments From davids at webmaster dot com 2005-02-20 19:43
---
>The reasoning is that dynamically created objects are often used locally in one
>thread, in which case locking would be unnecessary, while a singleton is always
>accessible to all threads.
Accessible, but not
--- Additional Comments From qrczak at knm dot org dot pl 2005-02-20 13:00
---
> There is certainly the eternal argument whether a class should implement its
> own
> locks internally or whether the caller should implement them.
And my guideline is as follows: it should implement its ow
--- Additional Comments From davids at webmaster dot com 2005-02-20 10:48
---
There is certainly the eternal argument whether a class should implement its own
locks internally or whether the caller should implement them. The first case
simplifies calling at the expense of overhead when
--- Additional Comments From qrczak at knm dot org dot pl 2005-02-20 10:16
---
> You cannot create code that works with this option and doesn't work without it
> except by violating the POSIX standard. So POSIX code should not have this
> option enabled by default -- it's a pure pessimiz
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-20
06:21 ---
No, the point is if you expose an API to the user, why should the user of the
API know that you modify
the memory.
Let the compiler do the work for you instead of doing the work in this case.
--
--- Additional Comments From davids at webmaster dot com 2005-02-20 02:50
---
You say, "how can someone know that A will modify memory"? The answer is, the
C++ standard says so, section 7.1.2. They simply read that section of the
standard, and they know that the function might modify me
--- Additional Comments From davids at webmaster dot com 2005-02-20 02:46
---
In your example:
class A
{
A();
int t;
};
void f()
{
static A a;
}
I don't get it. What's the problem with this? Obviously, if you plan to call
'f()' from multiple threads, you must do it while holding
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-20
01:14 ---
No, see the following code:
class A
{
A();
int t;
};
void f()
{
static A a;
}
So how can someone know that A will modify memory? In fact the mutex is made
sure so that a is only
initialized once.
--- Additional Comments From davids at webmaster dot com 2005-02-20 01:09
---
Do we agree that this is a pure pessimization for POSIX-compliant code? Do we
agree that POSIX already requires a mutex to protect code that might modify an
object?
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-20
01:01 ---
Actually this code was added because well it is hard to deal with mutexies in
these cases.
--
What|Removed |Added
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-20
00:52 ---
Note -fthreadsafe-statics, never made it into the FSF's 3.4.x, only 4.0.0.
Also note this is required by the C++ ABI.
--
What|Removed |Added
27 matches
Mail list logo
