How to write thread-safe code?
Alexander Terekhov
"Slava M. Usov" wrote:
>
> "Alexander Terekhov" <tere...@web.de> wrote in message
> news:3CEA6195...@web.de...
>
> > How fascinating, Slava! ;-)
> >
> > Here is some "real" stuff for OP to "start with":
>
> That stuff does not look any more real than what has already been suggested.
> I only bothered to check the first two links [which again, surprise
> surprise, lead us to Alexander lecturing]. The first link was irrelevant
> because the OP did not even ask about exception safety, he asked about
"similarities" w.r.t achieving/implementing BOTH concepts
aside, another person "asked"/mentioned it (i.e. exception
safety) in this "How to write thread-safe code?" thread.
That person ("Fred Jackson") was quite correct and wise
to mention it...
> thread safety. I posted that pseudocode only to illustrate one of the ways
> to couple thread safety with exceptions, not more [C++ exceptions are
> discussed elsewhere, unless we discuss interactions between SEH and C++
> exceptions]. The second was irrelevant for the reason that Win32, by
> definition, is not POSIX.
I've posted the following links:
http://groups.google.com/groups?selm=3CBF0501.8314BB2C%40web.de
(Subject: Re: Exception handling)
http://groups.google.com/groups?threadm=3C2CE9F9.838A79B9%40web.de
(Subject: Re: What is meant by Thread Safety???)
http://groups.google.com/groups?threadm=abavvb%24ouu%241%40eng-ser1.erg.cuhk.edu.hk
(Subject: mutex should be static or not ?)
http://groups.google.com/groups?threadm=abh8jl%244sg%241%40sunsite.icm.edu.pl
(Subject: Thread safety of cout)
The second one was "Re: What is meant by Thread Safety???"
Are you saying that me-stupid/me-uninformed somehow managed
to miss {recent} Microsoft invention of BETTER THREAD SAFETY
(Win32-specific, I mean)? Where can I find that newspaper?!?
regards,
alexander.
Slava M. Usov
> < cross-posted to c.p.t >
> "similarities" w.r.t achieving/implementing BOTH concepts
> aside, another person "asked"/mentioned it (i.e. exception
> safety) in this "How to write thread-safe code?" thread.
> That person ("Fred Jackson") was quite correct and wise
> to mention it...
Yeah, mention, not to switch from thread safety to exception safety. Are you
unable to differentiate between the two? Given your keyword style of reading
and non-sequitur style of writing, I'm not all that surprised, though.
[...]
> > The second was irrelevant for the reason that Win32, by
> > definition, is not POSIX.
>
> I've posted the following links:
>
> http://groups.google.com/groups?selm=3CBF0501.8314BB2C%40web.de
> (Subject: Re: Exception handling)
Which is clearly inappropriate given the subject line.
> http://groups.google.com/groups?threadm=3C2CE9F9.838A79B9%40web.de
> (Subject: Re: What is meant by Thread Safety???)
[...]
> The second one was "Re: What is meant by Thread Safety???"
Do you even care to read articles written by yourself, if you're so fond of
citing yourself? Did you not notice that in that article you had merely
cited POSIX standard? Do you still have difficulties distinguishing between
win32 and POSIX? Do I have to wade through that excerpt and annotate almost
every line "does not apply to win32"? What are you smoking there?
> Are you saying that me-stupid/me-uninformed somehow managed
> to miss {recent} Microsoft invention of BETTER THREAD SAFETY
> (Win32-specific, I mean)? Where can I find that newspaper?!?
Where did I say anything like that? Having more reading comprehension
problems? I said that
[begin quote]
The second was irrelevant for the reason that Win32, by
definition, is not POSIX.
[end quote]
How can that be relevant if the very first line of that says
"Async-Signal-Safe Function". What is Async-Signal in win32? The whole idea
of win32 is that it specifically does not have any asynchronous signals!
Even if _you_ say it is a win32 exception, what in the world will guarantee
that MS thinks the same, that they have read that POSIX paper, and
especially that they have decided to make a few of the routines listed there
POSIX compliant [a few because only the socket routines are a part of win32,
the rest of them is either not known to win32 programs or is implemented by
CRT and is specifically _not_ recommended to use by MS].
Why is it so difficult to grasp that win32 is _not_ POSIX? Regardless of
ISO, ANSI, IEEE and whatnot, POSIX standards are meaningless for win32. Do
you ever try to speak Russian according to English grammar or vice versa?
What you're doing by referring to POSIX in strictly win32 discussion is very
similar to that. Not to mention that the contents of most of your messages
in general is similar to saying that English grammar is superior to Russian
grammar, or vice versa. And that you don't seem to realize that is most
amazing, given your general fluency in technical questions.
S
Alexander Terekhov
> "Alexander Terekhov" <tere...@web.de> wrote in message
> news:3CED4F25...@web.de...
> > < cross-posted to c.p.t >
> > "similarities" w.r.t achieving/implementing BOTH concepts
> > aside, another person "asked"/mentioned it (i.e. exception
> > safety) in this "How to write thread-safe code?" thread.
> > That person ("Fred Jackson") was quite correct and wise
> > to mention it...
>
> Yeah, mention, not to switch from thread safety to exception safety. Are you
> unable to differentiate between the two?
Hehe. Ok. Ok. Here is a 'hint' for you: *invariants*. Does this help? ;-)
[...]
> > > The second was irrelevant for the reason that Win32, by
> > > definition, is not POSIX.
> >
> > I've posted the following links:
> >
> > http://groups.google.com/groups?selm=3CBF0501.8314BB2C%40web.de
> > (Subject: Re: Exception handling)
>
> Which is clearly inappropriate given the subject line.
See above.
> > http://groups.google.com/groups?threadm=3C2CE9F9.838A79B9%40web.de
> > (Subject: Re: What is meant by Thread Safety???)
>
> [...]
>
> > The second one was "Re: What is meant by Thread Safety???"
>
> Do you even care to read articles written by yourself,
Yep.
> if you're so fond of citing yourself?
What's wrong with it? I just try to save bandwidth, to begin with.
Why should I 'repeat' the stuff that is literally ONE CLICK AWAY
*and* in the 'proper' context.... pointing other {counter} opinions
as well?! Y'know, I'm going to cite our various recent c.p.t-thoughts-
exchanges with you Slava too, in the future... Is this OK? Why NOT?
> Did you not notice that in that article you had merely
> cited POSIX standard?
Yes, I did.
> Do you still have difficulties distinguishing between
> win32 and POSIX?
Yes, I do. Really (w.r.t. THREAD-SAFETY). No jokes.
> Do I have to wade through that excerpt and annotate almost
> every line "does not apply to win32"?
Yes, please. To make it a bit easier for you, here is
a few IRRELEVANT (w.r.t. Win32, I mean) quotes from my
article on thread-safety ('regards' and 'p.s.' included)
that I'd like to gently ask you to *annotate* a bit:
"3.313 Reentrant Function
A function whose effect, when called by two
or more threads, is guaranteed to be as if
the threads each executed the function one
after another in an undefined order, even if
the actual execution is interleaved."
"3.396 Thread-Safe
A function that may be safely invoked concurrently
by multiple threads. ....
Examples are any "pure" function, a function which
holds a mutex locked while it is accessing static
storage, or objects shared among threads."
"pure" functions/memory synchronization:
"4.10 Memory Synchronization
Applications shall ensure that access to any memory
location by more than one thread of control (threads
or processes) is restricted such that no thread of
control can read or modify a memory location while
another thread of control may be modifying it. Such
access is restricted using functions that synchronize
thread execution and also synchronize memory with
respect to other threads. The following functions
synchronize memory with respect to other threads:
.....
Applications may allow more than one thread of control
to read a memory location simultaneously."
regards,
alexander.
p.s. the term "memory location" (memory granule) is
undefined, unfortunately; there is no *portable* way
of fighting "word-tearing" race condition (e.g. multiple
threads modifying portions of array of characters with
some portion(s) equal to one char; even if portions are
shared and protected by mutexes) and MP-performance
problem of false-sharing (cached memory granularity),
AFAIK.
Hillel Y. Sims
> p.s. the term "memory location" (memory granule) is
> undefined, unfortunately; there is no *portable* way
> of fighting "word-tearing" race condition (e.g. multiple
> threads modifying portions of array of characters with
> some portion(s) equal to one char; even if portions are
> shared and protected by mutexes) and MP-performance
> problem of false-sharing (cached memory granularity),
> AFAIK.
sig_atomic_t?
hys
--
Hillel Y. Sims
hsims AT factset.com
t...@cs.ucr.edu
[...]
: How can that be relevant if the very first line of that says
: "Async-Signal-Safe Function". What is Async-Signal in win32? The whole idea
: of win32 is that it specifically does not have any asynchronous signals!
So, under Win32, kernel-initiated communication with user-mode threads
requires polling by that thread. Right?
If so, that seems unfortunately restrictive, but no more so than the
C/C++ standards themselves, where signal handlers can't read and
can write global variables of type "volatile sigatomic_t" only.
Tom Payne
t...@cs.ucr.edu
[...]
: p.s. the term "memory location" (memory granule) is
: of fighting "word-tearing" race condition (e.g. multiple
: threads modifying portions of array of characters with
: some portion(s) equal to one char; even if portions are
: shared and protected by mutexes) and MP-performance
: problem of false-sharing (cached memory granularity),
: AFAIK.
I'm of the (possibly naive) impression that databases allow this sort
of thing all the time. AFAIK, they use fine-grain locking and
multistage-commit protocols. Tedious stuff but doable.
Tom Payne
t...@cs.ucr.edu
: "Alexander Terekhov" <tere...@web.de> wrote in message
: sig_atomic_t?
FWIW, the language lawyers tell me that the standards guarantee the
atomicity of objects of type sig_atomic_t only when they are accessed
from signal handlers. ;-)
Tom Payne
Alexander Terekhov
http://groups.google.com/groups?as_umsgid=3B02A7A4.C6FEDC23%40dvv.org
http://groups.google.com/groups?selm=3B0E5122.A574104D%40web.de
Also (and I just hope that Konrad won't kill me for this):
email-exchange/off-band stuff w.r.t. one of my XBD 'aardvarks':
-----
> But, all in all, I feel validated. The fact that EV4 and EV5 are
> slow in accessing bytes is their problem and was "fixed" in
> later releases of the architecture. If you want to remain
> backwards-compatible, that is up to you, but I think this
> whole word-tearing thing is a legacy quirk that won't play
> much of a role in the future.
Well, consider:
http://groups.google.com/groups?selm=qXU47.813%24rc5.60656%40news.cpqcorp.net
(Subject: Re: Most conforming POSIX threads implementation)
"Norman Black wrote:
> Generally speaking, if a processor supports a data type directly in
> load/store instructions then that instruction will operate atomically with
> respect to other processors.
>
> The SPARC, MIPS, PowerPC/POWER, IA-64 architectures all support 8 and
> 16-bit writes. This is NOT true for the Alpha however.
That hasn't been true since the EV56, which is now pretty old. However, the
compiler will still generally try to write code that can be executed by any
old Alpha unless you use the -arch switch. (Ironically, the addition of
byte and word instructions was mostly a concession to the economic
realities of porting NT device drivers... which may have already become
irrelevant by the time EV56 shipped, but certainly soon after.)
Still, more importantly, the C and C++ languages don't guarantee what
operations will be used to read or write your data, even when the hardware
happens to support an operation that would do the job atomically. So
whether the hardware can do it is really irrelevant unless you're writing
in assembler."
Also, you might want to take a look at this (please don't
miss "distinct"/"#define GRANULARIZE(X)" stuff/link ;-)):
http://groups.google.com/groups?selm=3C428BC0.1D5F2D90%40web.de
(Subject: Re: Is this code correct ?)
> But then what constructs could be portably treated as different memory
> locations ? In other words how then could we write portable programs ?
Hey, Dmitri, I've told you that this might be even
funny... Personally, I think that having just
PORTABILITY (things defined in the standard) in
mind, this whole topic could be characterized along
the lines of the remark the author of the article
you have replied to once wrote about recursive
trylock()ing (on recursive mutex):
"In a way, the defined semantics are as undefined
as the undefined semantics. That always makes for
a fun game."
For example, you might want to have a look at
"distinct"/"#define GRANULARIZE(X)" sub-thread:
http://groups.google.com/groups?as_umsgid=3B55DC62.2CCE3B26%40web.de
The other extreme (IMHO) is the JVM's:
http://www.cs.umd.edu/~pugh/java/memoryModel/semantics.pdf
"The fact that two variables may be stored in ad-
jacent bytes (e.g., in a byte array) is immaterial.
Two variables can be simultaneously updated by
different threads without needing to use synchro-
nization to account for the fact that they are
'adjacent'. Any word-tearing must be invisible
to the programmer."
And even they (VM folks) do NOT solve the problem
of "false sharing", AFAIK.
regards,
alexander.
Please respond to {censored}
To: Alexander Terekhov
cc: David.B...@HP.com
Subject: RE: ERN 9 (Defect in XBD 4.10 Memory Synchronization (rdvk# 26))
> -----Original Message-----
> From: Alexander Terekhov [mailto:{censored}]
> Sent: Tuesday, May 21, 2002 7:04 PM
> To: {censored}
> Cc: David.B...@HP.com
> Subject: RE: ERN 9 (Defect in XBD 4.10 Memory Synchronization (rdvk#
> 26))
>
>
>
>
> < respected c.p.t poster is on CC now... given the ARH9RBTE's quoting
> below; hopefully, that could help to clarify the matters a
> bit!!!!! >
Hello Mr. Butenhof, I hope we aren't bothering you too much.
To put some context into this message, Alexander Terekhov
tried to get word-tearing problems into POSIX. I said this
is unnecessary, because all known machines can generate code
sequences so that word-tearing is not a problem. In particular,
old Alphas can use load-locked/store-conditional to avoid problems.
This suggestion, incidentally, comes from Fred Kleinsorg of
VMS engineering, a poster to comp.arch.
> > Yes, I would make it the default mode. The compiler could
[namely generate load-locked/store-conditional]
> > try to do some sort of alias detection to improve the code in
> > certain cases, but, all in all, it is at most a 25% increase in
> > the code size---for a data type that is not that common/performance
> > critical. In loops (examining the characters in a string), a
> > naive approach to modifying individual bytes will notice the
> > extra branch even less.
>
> Well, consider:
>
> http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V5
> 1_HTML/ARH9RBTE/DOCU0008.HTM
>
> "....
> 3.7.5.2 Maintaining the Composite Data Object's Layout
>
> If you cannot change the organization or layout of the
> composite data object's definition, you should do one
> of the following:
>
> (On OpenVMS Alpha or OpenVMS VAX) Compile all application
> modules for byte actual granularity. Doing so automatically
> prevents word-tearing race conditions for structure or
> union members and array elements of size byte or
> larger that are accessed concurrently by different threads.
> No other program modification is required. This may have
> a performance penalty on Alpha EV4 and EV5 processors.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Or,
>
> (On Tru64 UNIX systems) For arrays, add the C language
> volatile storage qualifier to the definition of the
> entire array; for structures, add volatile to the
> declaration of only those members that share the
> pertinent memory granule. You must also compile the
> application's modules using the Compaq C or Compaq C++
> compiler's -strong-volatile switch. Doing so causes
> the compiler to produce code that forces all accesses
> to those members to occur as atomic operations. See
> the description of the -strong-volatile switch
> in the Compaq C or Compaq C++ documentation
> and on the cc reference page.
> This may also have a severe performance penalty.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ...."
>
> http://www.tru64unix.compaq.com/dtk/misc_docs/man/cc.1.html
>
> "....
> -strong_volatile
> Affects the generation of code for assignments to
> objects that are
> less
> than or equal to 16 bits in size (for instance char,
> short) that have
> been declared as volatile. The generated code includes
> a load-locked
> instruction for the enclosing longword or quadword, an
> insertion of
> the
> new value of the object, and a store-conditional
> instruction for the
> enclosing longword or quadword. By using this locked instruction
> sequence for byte and word stores, the -strong_volatile
> option allows
> byte and word access of data at byte granularity.
> This means
> that
> assignments to adjacent volatile small objects by
> different threads
> in
> a multithreaded program will not cause one of the
> objects to receive
> an
> incorrect value.
> ...."
>
Its interesting for me that load-locked/store-conditional can lead
to a large slow down.
But, all in all, I feel validated. The fact that EV4 and EV5 are
slow in accessing bytes is their problem and was "fixed" in
later releases of the architecture. If you want to remain
backwards-compatible, that is up to you, but I think this
whole word-tearing thing is a legacy quirk that won't play
much of a role in the future.
> > Signals already have the sig_atomic_t so that single-threaded code
> > can use the simpler access sequences.
>
> Nope. "Signals" have *volatile static sig_atomic_t* variables,
> which strictly/"legally" speaking, has NOTHING to do with threads:
I didn't say that. What I was trying to say is that signal handlers
may only access variables of type sig_atomic_t and so a correct signal
handler can't have problems with word tearing.
> http://groups.google.com/groups?threadm=3CBC3EAF.2A86389%40web.de
>
> regards,
> alexander.
>
>
> {censored} on 05/14/2002
> 09:31:23 AM
>
> Please respond to {censored}
>
> To: Alexander Terekhov
> cc:
> Subject: RE: ERN 9 (Defect in XBD 4.10 Memory
> Synchronization (rdvk#
> 26))
>
>
> Yes, I would make it the default mode. The compiler could
> try to do some sort of alias detection to improve the code in
> certain cases, but, all in all, it is at most a 25% increase in
> the code size---for a data type that is not that common/performance
> critical. In loops (examining the characters in a string), a
> naive approach to modifying individual bytes will notice the
> extra branch even less.
>
> Signals already have the sig_atomic_t so that single-threaded code
> can use the simpler access sequences.
>
> Regards,
> Konrad
> {sig.censored}
>
> > -----Original Message-----
> > From: Alexander Terekhov [mailto:{censored}]
> > Sent: Monday, May 13, 2002 6:36 PM
> > To: {censored}
> > Subject: RE: ERN 9 (Defect in XBD 4.10 Memory Synchronization (rdvk#
> > 26))
> >
> >
> >
> > Yes, I think so (something like that emulating "byte" granularity).
> > But how would you express it in C/POSIX? Or do you want to make it
> > the "default mode" for any "teared" data, no matter whether it is
> > thread-shared or totally thread-private?!
> >
> > regards,
> > alexander.
> >
> > P.S. It seems that Compaq is/was using "volatiles" (impl.specific;
> > NON_STANDARD semantics) to differentiate...
> >
> >
> >
> > {censored} on 05/13/2002
> > 05:30:49 PM
> >
> > Please respond to {censored}
> >
> > To: Alexander Terekhov
> > cc:
> > Subject: RE: ERN 9 (Defect in XBD 4.10 Memory
> > Synchronization (rdvk#
> > 26))
> >
> >
> > Suppose I want to modify a byte on a machine that has word
> > size access:
> >
> > code without thread/signal safety:
> >
> > ld rX, location
> > and rX, mask
> > or rX, shifted_value
> > st location, rX
> >
> > code with thread/signal safety:
> >
> > 1: ld-lock rX, location
> > and rX, mask
> > or rX, shifted_value
> > st-cond location, rX
> > bf 1p
> >
> > Doesn't this solve the problem?
> >
> > Regards,
> > Konrad
> > {sig.censored}
> >
> > > -----Original Message-----
> > > From: Alexander Terekhov [mailto:{censored}]
> > > Sent: Monday, May 13, 2002 11:10 AM
> > > To: {censored}
> > > Subject: RE: ERN 9 (Defect in XBD 4.10 Memory
> Synchronization (rdvk#
> > > 26))
> > >
> > >
> > >
> > >
> > >
> > > > can't word tearing be solved by load-lock/store conditional
> > > > on machines that don't support atomic writes to bytes?
> > > > That is, the compiler needs to generate ll/sc loops
> > > > instead of load/store sequences when accessing bytes.
> > > > This would mean that machines that don't support ll/sc and
> > > > don't support atomic byte writes would not be able to support
> > > > POSIX, but does this have any practical relevance?
> > >
> > > http://groups.google.com/groups?selm=3CBC3EAF.2A86389%40web.de
> > > (see "...FYI on memory 'granularity'" link)
> > >
> > > regards,
> > > alexander.
> > >
> > > P.S. Do you really want to keep it "out-of-band" (AG's reflector,
> > > I mean)? ;-) Feel free to send your response to this message (if
> > > any) to austin-...@opengroup.org ;-) ;-)
> > >
> > >
> > >
> > > {censored} on 05/13/2002
> > > 09:49:06 AM
> > >
> > > Please respond to {censored}
> > >
> > > To: Alexander Terekhov/Germany/IBM@IBMDE
> > > cc:
> > > Subject: RE: ERN 9 (Defect in XBD 4.10 Memory
> > > Synchronization (rdvk#
> > > 26))
> > >
> > >
> > > Hello,
> > > can't word tearing be solved by load-lock/store conditional
> > > on machines that don't support atomic writes to bytes?
> > > That is, the compiler needs to generate ll/sc loops
> > > instead of load/store sequences when accessing bytes.
> > > This would mean that machines that don't support ll/sc and
> > > don't support atomic byte writes would not be able to support
> > > POSIX, but does this have any practical relevance?
> > >
> > > Konrad {sig.censored}
> > >
> > >
> > > > -----Original Message-----
> > > > From: Alexander Terekhov [mailto:{censored}]
> > > > Sent: Friday, May 10, 2002 6:22 PM
> > > > To: austin-group-l@{censored}
> > > > Subject: ERN 9 (Defect in XBD 4.10 Memory Synchronization
> > > (rdvk# 26))
> > > >
> > > >
> > > >
> > > > http://www.opengroup.org/austin/docs/austin_107.txt
> > > >
> > > > "....
> > > > Our advice is as follows.
> > > >
> > > > Hardware that does not allow atomic accesses cannot have
> > > > a POSIX implementation on it.
> > > >
> > > > ...."
> > > >
> > > > Excuse me, but does this mean that the following
> > > > (piece of informal memory model semantics) applies
> > > > to POSIX "memory model" as well:
> > > >
> > > > http://www.cs.umd.edu/~pugh/java/memoryModel/semantics.pdf
> > > >
> > > > "....
> > > > The fact that two variables may be stored in ad-
> > > > jacent bytes (e.g., in a byte array) is immaterial.
> > > > Two variables can be simultaneously updated by
> > > > different threads without needing to use synchro-
> > > > nization to account for the fact that they are
> > > > 'adjacent'. Any word-tearing must be invisible
> > > > to the programmer.
> > > > ...."
> > > >
> > > > <?>
> > > >
> > > > And/or, perhaps, what is actually meant by the "advice"
> > > > above is that the *undefined* term "memory location"
> > > > is actually a substitute of *defined* POSIX "Byte" term
> > > > (C-"char"/CHAR_BIT==8 required) or something like that?
> > > >
> > > > TIA.
> > > >
> > > > regards,
> > > > alexander.
> > > >
> > > >
> > > > Andrew Josey <{censored}> on 05/10/2002
> 04:42:01 PM
> > > >
> > > > Please respond to {censored} (Andrew Josey)
> > > >
> > > > To: austin-group-l@{censored}
> > > > cc:
> > > > Subject: Aardvark reports (XBD,XCU,XRAT) from the meeting
> > > >
> > > >
> > > > All
> > > > The initial aardvark reports for XBD, XCU and XRAT are now
> > > > in the document register in Austin/107,108,and 109 respectively.
> > > >
> > > > Reviewers are asked to inspect these reports, and are kindly
> > > > requested to indicate to the reflector if they take issue
> > > > with any decisions of the review team by May 24, when
> the reports
> > > > will be finalized.
> > > >
> > > > regards
> > > > Andrew
> > > >
> > > > -----
> > > > Andrew Josey The Open Group
> > > > {sig.censored}
Hillel Y. Sims
>
> "Hillel Y. Sims" wrote:
> >
> > sig_atomic_t?
>
> http://groups.google.com/groups?selm=3B0E5122.A574104D%40web.de
>
<quote>
Dave Butenhof wrote:
[...]
> What's lacking, perhaps, is a requirement that some particular C data size
is "safe"; that
> all possible machines ? compilers must support and maintain a definition
of "a memory
> location" no larger than some type, such as "int" or "long". The logical
candidate here
> would be sig_atomic_t. Though the requirement isn't spelled out, this must
have the required
> characteristics in order to be safe for signal handler access as
specified.
</quote>
(but I guess it's just a "candidate" not actual guarantee.. yet? ;-)
Slava M. Usov
> > Yeah, mention, not to switch from thread safety to exception safety. Are
> > you unable to differentiate between the two?
>
> Hehe. Ok. Ok. Here is a 'hint' for you: *invariants*. Does this help? ;-)
BS. Just about everything there is to programming boils down to invariants
and preserving thereof. Theoretically.
[...]
> > if you're so fond of citing yourself?
>
> What's wrong with it? I just try to save bandwidth, to begin with.
> Why should I 'repeat' the stuff that is literally ONE CLICK AWAY
> *and* in the 'proper' context.... pointing other {counter} opinions
> as well?! Y'know, I'm going to cite our various recent c.p.t-thoughts-
> exchanges with you Slava too, in the future... Is this OK? Why NOT?
The views of everybody who participates in a discussion are biased. When you
refer to yourself, that is just another biased view. As for the context, it
is BS and you know that. If you really believe that everybody is going to
read the whole discussion, so why don't you refer to your opponent in that
discussion?
Secondly, a huge portion of what you refer to is irrelevant and it is quite
boring to read through and click through zillions of links in your messages,
and in the messages of yours referenced by the messages of yours and so on
ad nausea. A relevant quote would be far better but you of course cannot
afford that because as soon as you filter all the irrelevant things out you
do not have any arguments at all, as I'm going to show below.
> > Do you still have difficulties distinguishing between
> > win32 and POSIX?
>
> Yes, I do. Really (w.r.t. THREAD-SAFETY). No jokes.
For general issues, there is a lot of similarity. But I'm afraid that no
POSIX standard will address those general issues
_in_a_way_making_sense_for_win32. When you quote a POSIX standard that says
"these POSIX functions are thread-safe", that standard is clearly pointless
when it comes to win32, even if it defines what thread-safe is. More on that
below.
> > Do I have to wade through that excerpt and annotate almost
> > every line "does not apply to win32"?
>
> Yes, please. To make it a bit easier for you, here is
> a few IRRELEVANT (w.r.t. Win32, I mean) quotes from my
> article on thread-safety ('regards' and 'p.s.' included)
> that I'd like to gently ask you to *annotate* a bit:
Oh, how nice. You gave us three extremely valuable definitions. Now what?
How does that help to answer a single question about win32? For POSIX, there
was a huge list of functions which have certain attributes according to
these definitions, but for win32 it does not help a bit. How are your
definitions going to help when given a win32 function X one needs to
determine whether it is reentrant, thread-safe or does memory
synchronization?
[...]
> "4.10 Memory Synchronization
>
> Applications shall ensure that access to any memory
> location by more than one thread of control (threads
> or processes) is restricted such that no thread of
> control can read or modify a memory location while
> another thread of control may be modifying it. Such
> access is restricted using functions that synchronize
> thread execution and also synchronize memory with
> respect to other threads. The following functions
> synchronize memory with respect to other threads:
>
> .....
Yes, please! Quote that standard to give us a list of win32 functions that
"synchronize memory with respect to other threads".
> p.s. the term "memory location" (memory granule) is
> undefined, unfortunately; there is no *portable* way
> of fighting "word-tearing" race condition (e.g. multiple
> threads modifying portions of array of characters with
> some portion(s) equal to one char; even if portions are
> shared and protected by mutexes) and MP-performance
> problem of false-sharing (cached memory granularity),
> AFAIK.
Which makes that definition next to useless and forces the programmer to
over-serialize things. E.g., IA 32 guarantees atomical reads and writes of
bytes, 2-byte aligned 2-byte words, and 4-byte aligned 4-byte words, and
even 8-bytes word on certain CPUs. Even on SMP, yes. As soon as you start
following that "portable" and pointless definition on IA 32, performance is
gone fishing. No, thanks.
S
Slava M. Usov
> In comp.programming.threads Slava M. Usov <stripit...@gmx.net> wrote:
> [...]
> : How can that be relevant if the very first line of that says
> : "Async-Signal-Safe Function". What is Async-Signal in win32? The whole
> : idea of win32 is that it specifically does not have any asynchronous
> : signals!
>
> So, under Win32, kernel-initiated communication with user-mode threads
> requires polling by that thread. Right?
Typically waiting on an KM object, such as a file handle [sockets are file
handles], event, or completion port. There are also user-mode APCs which are
a sort of async signals, but they are only delivered when the thread is in a
state that allows their delivery, and the thread must explicitly enter that
state. This stuff is largely not used because of the prevailing win32
paradigm "no async anything". I guess MS/IBM burned their fingers badly on
the reentrancy issues pertaining to *-DOS so they cursed and abolished
anything that could lead to that. Then they added exceptions mostly
recreating the whole thing. So much for the OSes created by groups of
"experts" :-) OK, exceptions are not completely analogous to signals,
because they result from the actions of the thread, which is not completely
"asynchronous", and, more importantly, because most of win32 programs just
ignore all exceptions. I'm not talking about C++ exceptions here, I'm
talking about OS-generated exceptions, such as access violations.
> If so, that seems unfortunately restrictive, but no more so than the
> C/C++ standards themselves, where signal handlers can't read and
> can write global variables of type "volatile sigatomic_t" only.
Seem it may, but actually this is not needed. Part of what signals do is
covered by exceptions, another part does not apply to win32, and the
remaining things are doable by means of waiting. Waiting is not a problem in
win32 because it has always been multithreaded and you could always spawn a
thread or use a worker thread to wait on something without blocking the
whole process.
S
Alexander Terekhov
"Slava M. Usov" wrote:
[...]
> > > if you're so fond of citing yourself?
> >
> > What's wrong with it? I just try to save bandwidth, to begin with.
> > Why should I 'repeat' the stuff that is literally ONE CLICK AWAY
> > *and* in the 'proper' context.... pointing other {counter} opinions
> > as well?! Y'know, I'm going to cite our various recent c.p.t-thoughts-
> > exchanges with you Slava too, in the future... Is this OK? Why NOT?
>
> The views of everybody who participates in a discussion are biased. When you
> refer to yourself, that is just another biased view.
Yep. So, what's wrong with "just another biased view" pointing
to [google's "View: Complete Thread (N articles)" link] *other*
biased views as well?
> As for the context, it is BS and you know that.
How do you know that (that[what] I know, I mean)? ;-)
> If you really believe that everybody is going to
> read the whole discussion,
No, I don't (*everybody* is NOT going to read the whole discussion).
> so why don't you refer to your opponent in that discussion?
I do -- you should just learn how to use google netnews archives and
how to click on links -- "View: Complete Thread (N articles)" links.
> Secondly, a huge portion of what you refer to is irrelevant and it is quite
> boring to read through and click through zillions of links in your messages,
> and in the messages of yours referenced by the messages of yours and so on
> ad nausea.
Don't "read through and click through zillions of links",
keep your mouth closed, then.
> A relevant quote would be far better but you of course cannot
> afford that because as soon as you filter all the irrelevant things out you
> do not have any arguments at all, as I'm going to show below.
Let's see...
> > > Do you still have difficulties distinguishing between
> > > win32 and POSIX?
> >
> > Yes, I do. Really (w.r.t. THREAD-SAFETY). No jokes.
>
> For general issues, there is a lot of similarity. But I'm afraid that no
> POSIX standard will address those general issues
> _in_a_way_making_sense_for_win32. When you quote a POSIX standard that says
> "these POSIX functions are thread-safe", that standard is clearly pointless
> when it comes to win32, even if it defines what thread-safe is. More on that
> below.
>
> > > Do I have to wade through that excerpt and annotate almost
> > > every line "does not apply to win32"?
> >
> > Yes, please. To make it a bit easier for you, here is
> > a few IRRELEVANT (w.r.t. Win32, I mean) quotes from my
> > article on thread-safety ('regards' and 'p.s.' included)
> > that I'd like to gently ask you to *annotate* a bit:
>
> Oh, how nice. You gave us three extremely valuable definitions.
Yes, I believe.
> Now what?
K.. ahah.. well.
> How does that help to answer a single question about win32?
No comments. Try again.
> For POSIX, there was a huge list of functions
I've snipped them.
> which have certain attributes according to
> these definitions, but for win32 it does not help a bit.
I've snipped them.
> How are your
> definitions going to help when given a win32 function X one needs to
> determine whether it is reentrant, thread-safe or does memory
> synchronization?
My, the question was: HOW TO WRITE (>>WRITE<<) THREAD-SAFE CODE?
(see the "subject"-thing 'above' in your newsreader or whatever)
NOT: what are the win32' thread-safe/reentrant/whatever >>MS<<
written/provided funcs/APIs.
[...]
> > "4.10 Memory Synchronization
> >
> > Applications shall ensure that access to any memory
> > location by more than one thread of control (threads
> > or processes) is restricted such that no thread of
> > control can read or modify a memory location while
> > another thread of control may be modifying it. Such
> > access is restricted using functions that synchronize
> > thread execution and also synchronize memory with
> > respect to other threads. The following functions
> > synchronize memory with respect to other threads:
> >
> > .....
>
> Yes, please! Quote that standard to give us a list of win32 functions that
> "synchronize memory with respect to other threads".
You are kidding. MS.. and 'standard'... ROFLWTIME! Thanks!!
Well <after a minute or two ROFLing>, Slava, click here:
http://groups.google.com/groups?selm=c29b5e33.0202140541.7df2bb9d%40posting.google.com
(Subject: Re: Can multiple threads set a global variable simultaneously?)
Here's MS-stuff/quote specifically for you... so that you
could save some amount of your 'finger-clicking' energy:
"....
Functions which enter or leave critical sections.
Functions which signal synchronization objects.
Wait functions.
Interlocked functions
...."
> > p.s. the term "memory location" (memory granule) is
> > undefined, unfortunately; there is no *portable* way
> > of fighting "word-tearing" race condition (e.g. multiple
> > threads modifying portions of array of characters with
> > some portion(s) equal to one char; even if portions are
> > shared and protected by mutexes) and MP-performance
> > problem of false-sharing (cached memory granularity),
> > AFAIK.
>
> Which makes that definition next to useless and forces the programmer to
> over-serialize things. E.g., IA 32 guarantees atomical reads and writes of
> bytes, 2-byte aligned 2-byte words, and 4-byte aligned 4-byte words, and
> even 8-bytes word on certain CPUs. Even on SMP, yes. As soon as you start
> following that "portable" and pointless definition on IA 32, performance is
> gone fishing. No, thanks.
bitteschoen, bittesehr. Others may want (and I don't
really insists on it) to click here:
http://groups.google.com/groups?selm=c29b5e33.0202150632.6d579f24%40posting.google.com
(Subject: Re: Can multiple threads set a global variable simultaneously?)
Oh, and, BTW, the following MS-stuff:
"....
Consequently, the multiprocessor race condition above can be repaired as follows:
void CacheComputedValue()
{
if (!fValueHasBeenComputed) {
iValue = ComputeValue();
InterlockedExchange((LONG*)&fValueHasBeenComputed, TRUE);
}
}
...."
>> IS 'BULLSHIT'/BRAIN-DAMAGED, IMNSHO <<
regards,
alexander.
P.S. < from one of >>my<< "messages, and in the messages of yours
referenced by the messages of yours and so on ad nausea",
referenced above [last link] >
"....
- with "do not ignore PTHREADS" I just wanted to
encourage you to write your code on top of PTHREAD
opaque objects (pthread_mutex_t), their methods
in C notation (pthread_mutex_lock) and their
return codes ONLY. Just pretend that PTHREADS
being the standard extension to ANSI C is
available universally. Now, but what about WIN32
and users who just do not want to download pthread-
win32 LGPL library, for example? NO PROBLEM.
Just include your own mini-pthreads-win32 impl
in your own distribution package. The same goes
for any other platform you might want to support
and which does not natively have PTHREADS on it.
To me, it is just like some home grown C++ file
streams on top of standard C fopen/fread/fwrite/etc,
or in other words, just imagine that <pthread.h>
will someday become <cthread> and some future C++
<thread{*}> features (btw thread_shared_ptr does
belong to them ;-) will be defined using "as if"
term with respect to C <cthread> features –
PTHREADS/*C*THREADS (they just should not forget
to destroy automatic C++ objects on cancel/exit –
raise some C++ cancel/exit exception ;-)"
Slava M. Usov
[...]
> > so why don't you refer to your opponent in that discussion?
>
> I do -- you should just learn how to use google netnews archives and
> how to click on links -- "View: Complete Thread (N articles)" links.
You misunderstood. My question was "why do you not DIRECTLY refer to an
article by your opponent and hope that your readers are qualified enough to
use Google to find your personal views"? Another point that I forgot to make
was generally regarding Google URLs as a means to quote a USENET article. I
remember a few years ago everybody was doing the same with Deja. All of
those links and the messages are devoid of context now. A respectful fate,
that.
> Don't "read through and click through zillions of links",
> keep your mouth closed, then.
It is closed, my friend.
> > Now what?
>
> K.. ahah.. well.
It was not very smart of you when you first did that. It's not smart now,
either. Do you want me to stop replying to your messages? Then you just say
it. Using that stupid kid-talk to piss me off? I thought you older than
that...
> > How does that help to answer a single question about win32?
>
> No comments. Try again.
How does that [citing POSIX standards] help to answer a single question
about win32?
> > For POSIX, there was a huge list of functions
>
> I've snipped them.
Yep, as irrelevant for win32.
> > which have certain attributes according to
> > these definitions, but for win32 it does not help a bit.
>
> I've snipped them.
Don't lose focus yet. I say "but for win32 it does not help a bit" to which
you reply "I've snipped them". Hello?
> > How are your
> > definitions going to help when given a win32 function X one needs to
> > determine whether it is reentrant, thread-safe or does memory
> > synchronization?
>
> My, the question was: HOW TO WRITE (>>WRITE<<) THREAD-SAFE CODE?
> (see the "subject"-thing 'above' in your newsreader or whatever)
>
> NOT: what are the win32' thread-safe/reentrant/whatever >>MS<<
> written/provided funcs/APIs.
Oh yeah. After you've cross-posted the thread to comp.programming.threads
you think you can easily speculate like that? The original question was in
a win32 newsgroup, so you may attach "in win32" to the subject line.
Are you magically discussing thread-safe code _in_general_ now? Then just
let me know [I don't expect you'll want to strip the now-irrelevant win32
newsgroup from the distribution list]. Another indication of the very high
value of this "general thread-safety" discussion is the OP does not
participate in it.
> > Yes, please! Quote that standard to give us a list of win32 functions
> > that "synchronize memory with respect to other threads".
>
> You are kidding. MS.. and 'standard'... ROFLWTIME! Thanks!!
Yep. MS and POSIX standard might be a good laugh. I'm glad that you finally
got that. It's only taken a few days.
[...]
> bitteschoen, bittesehr.
See, it does not hurt to be polite just for a change.
>
http://groups.google.com/groups?selm=c29b5e33.0202150632.6d579f24%40posting.
google.com
> (Subject: Re: Can multiple threads set a global variable simultaneously?)
How's that related? The only relevant stuff [to win32, of course] it
contains is:
1. Question about visibility. I agree that the MS documentation lacks proper
explanations on these matters. However, it does say "simple mechanism for
synchronizing access to a variable that is shared by multiple threads".
Next, given the implementation and the following quote from IA32 reference:
[begin qoute]
Locked operations are atomic with respect to all other memory
operations and all externally visible events. [...]
Locked instructions can be used to synchronize data written by
one processor and read by another processor.
For the P6 family processors, locked operations serialize all
outstanding load and store operations (that is, wait for them
to complete). This rule is also true for the Pentium 4 and Intel
Xeon processors, with one exception: load operations that
reference weakly ordered memory types (such as the WC memory type)
may not be serialized.
[end quote, Section 7.1.2.2. SOFTWARE CONTROLLED BUS LOCKING, Volume 3]
it is guaranteed that when you use Interlocked*() to access the variable,
you always have a consistent view. In fact this is not necessary because
IA32 reference says:
[begin quote]
Writes from the individual processors on the system bus are globally
observed [...]
[end quote, Section 7.2.2. Memory Ordering in the P6 Family Processors,
Volume 3].
2. IA32 barrier instructions. They are only relevant for the
"write-combined" type of memory [actually, type of caching perfromed on that
region of memory]. win32 does not use that [for obvious reasons :-)]
> "....
> Consequently, the multiprocessor race condition above can be repaired as
> follows:
>
> void CacheComputedValue()
> {
> if (!fValueHasBeenComputed) {
> iValue = ComputeValue();
> InterlockedExchange((LONG*)&fValueHasBeenComputed, TRUE);
> }
> }
> ...."
>
> >> IS 'BULLSHIT'/BRAIN-DAMAGED, IMNSHO <<
Agreed. I fail to trace any relation to the original POSIX "memory
synchronization" excerpt, though. You just do not want to stay on the same
topic, do you?
> "....
> - with "do not ignore PTHREADS" I just wanted to
> encourage you to write your code on top of PTHREAD
> opaque objects (pthread_mutex_t), their methods
> in C notation (pthread_mutex_lock) and their
> return codes ONLY."
How would I go about IO completion ports then?
S
Alexander Terekhov
"Slava M. Usov" wrote:
>
> "Alexander Terekhov" <tere...@web.de> wrote in message
> news:c29b5e33.02052...@posting.google.com...
> > "Slava M. Usov" <stripit...@gmx.net> wrote in message
> > news:<u#dREjxACHA.2524@tkmsftngp05>...
>
> > > Yeah, mention, not to switch from thread safety to exception safety. Are
> > > you unable to differentiate between the two?
> >
> > Hehe. Ok. Ok. Here is a 'hint' for you: *invariants*. Does this help? ;-)
I guess, I should have said/hinted: *invariants*/*transactions*... ;-) ;-)
>
> BS. Just about everything there is to programming boils down to invariants
> and preserving thereof. Theoretically.
Right... and, practically (for example ;-)):
http://groups.google.com/groups?selm=38192d73.19559206%40nntp.netcom.ca
(Subject: Guru of the Week #61: Solution)
"....
INTRODUCTION
=======================================================
Exception Safety Recap
----------------------
....
Summary
-------
....
Finally, consider two fundamental implications:
1. The Transactional Principle: All programming
operations should be considered as transactions,
with associated guarantees, and are amenable to this
new style of ACID transactional analysis. This
applies regardless of whether exceptions are
possible or absent.
...."
http://groups.google.com/groups?selm=3CDBC845.6ACAAC71%40web.de
(Subject: Re: mutex should be static or not ?)
"....
> And per-object:
> - when there is a lot of contention. More granular locking helps.
> - when the resources you are accessing are more tied to that particular
> object. This is really true in most situations, I think.
Gee! Forget about this "per-object" locking thing. *Objects*
(and their methods) aren't {generally} *observable application
specific* TRANSACTIONS on some thread-shared stuff -- THAT's
what is really needed to be "protected"/formed via locking
(NOT just this or that "object", which could actually be
thread-private [no locking needed at all] in many cases,
to begin with... would you EVER want/need SYNCHRONIZED
char/int/etc.built-in-type "classes" with "synchronized"
inc/dec/etc.?!).
....
P.S. Please don't tell me about MS-"interlocked" stuff. ;-)"
regards,
alexander.
Alexander Terekhov
"Slava M. Usov" wrote:
[...]
> > > so why don't you refer to your opponent in that discussion?
> >
> > I do -- you should just learn how to use google netnews archives and
> > how to click on links -- "View: Complete Thread (N articles)" links.
>
> You misunderstood. My question was "why do you not DIRECTLY refer to an
> article by your opponent and hope that your readers are qualified enough to
> use Google to find your personal views"?
That would be just 'too clever' thing to expect, I guess. ;-)
> Another point that I forgot to make
> was generally regarding Google URLs as a means to quote a USENET article. I
> remember a few years ago everybody was doing the same with Deja. All of
> those links and the messages are devoid of context now. A respectful fate,
> that.
Try this one: http://www.deja.com/dnquery.xp?QRY=Slava+comp.programming.threads
;-)
> > Don't "read through and click through zillions of links",
> > keep your mouth closed, then.
>
> It is closed, my friend.
I don't think so (w.r.t. 'closed'). ;-)
> > > Now what?
> >
> > K.. ahah.. well.
>
> It was not very smart of you when you first did that. It's not smart now,
> either. Do you want me to stop replying to your messages? Then you just say
> it. Using that stupid kid-talk to piss me off? I thought you older than
> that...
Well, I'm just kidding/relaxing a bit.
> > > How does that help to answer a single question about win32?
> >
> > No comments. Try again.
>
> How does that [citing POSIX standards] help to answer a single question
> about win32?
Yeah.. "how". OK. Forget it.
[...memory visibility...]
I'm not sure that you've fully understood it. It (sync/locking)
should be done BY EACH THREAD (at least once, in the {special}
case of lazy/once-init, for example) in order to work 'portably'...
Read that "Java/MP" paper, please.
> > "....
> > - with "do not ignore PTHREADS" I just wanted to
> > encourage you to write your code on top of PTHREAD
> > opaque objects (pthread_mutex_t), their methods
> > in C notation (pthread_mutex_lock) and their
> > return codes ONLY."
>
> How would I go about IO completion ports then?
Good question.
http://groups.google.com/groups?selm=3CA1E375.911DBB66%40web.de
(Subject: Re: Q: use CreateThread() and TerminateThread() and message procedure)
http://groups.google.com/groups?selm=c29b5e33.0202121418.26d77875%40posting.google.com
(Subject: Re: Novice: Exiting and starting threads.)
"....
TASKS/JOBS are OK (and I would really love to see (and use)
some "goal-driven" thread-pooling (throughput-oriented/LIFO
thread-pools with "optimal" system-controlled/auto-adjustable
concurrency (min. context switches), but taking into account
"optimal" bandwidth-/IO-utilization and average response times,
etc... become a part of some future Pthreads!), but they are
NOT *threads*, however!
....
http://groups.google.com/groups?selm=3C624903.E7E49271%40web.de
("Subject: Re: func performance [Re: Suspension of Linux threads.])
"....
> there's
> really no reason to avoid them. The only argument against using them is
> the completion ports are better.
Are there any chances to have something like
this (i.e. MS-style "completion ports" thread-
pooling[2] or even something better ;-) in some
future Pthreads? Perhaps Mr.Butenhof and a like
(I mean "real" Pthread-implementors/Austin Group
working group members/technical reviewers folks)
could elaborate... please!"
regards,
alexander.
Slava M. Usov
>
> "Slava M. Usov" wrote:
> > You misunderstood. My question was "why do you not DIRECTLY refer to an
> > article by your opponent and hope that your readers are qualified enough
> > to use Google to find your personal views"?
>
> That would be just 'too clever' thing to expect, I guess. ;-)
But the opposite thing is not "too clever to expect", right? So much for the
biased attitudes.
> > Another point that I forgot to make
> > was generally regarding Google URLs as a means to quote a USENET
> > article. I remember a few years ago everybody was doing the same with
> > Deja. All of those links and the messages are devoid of context now. A
> > respectful fate, that.
>
> Try this one:
http://www.deja.com/dnquery.xp?QRY=Slava+comp.programming.threads
That very well might work. However, I remember they had some sort of
internal IDs and many people got the habit of using them to reference the
messages. Do you think that will work? Even if they still work, do you think
that Google will last forever or just any significant time? Yeah, I was
wrong about "all links".
> > > Don't "read through and click through zillions of links",
> > > keep your mouth closed, then.
> >
> > It is closed, my friend.
>
> I don't think so (w.r.t. 'closed'). ;-)
Well, you know, I might even touch my lips with my fingers to assert that,
but given that I have no paralyses nor pareses of any kind I'm inclined to
trust the short path of neurons going from my mouth to my brain rather than
execute the long path spanning my arm, chest, and the spinal cord.
[...]
> [...memory visibility...]
>
> I'm not sure that you've fully understood it. It (sync/locking)
> should be done BY EACH THREAD (at least once, in the {special}
> case of lazy/once-init, for example) in order to work 'portably'...
> Read that "Java/MP" paper, please.
'Portable'. Makes no sense for win32 :-) And because you're posting to a
win32 newsgroup it ought to make sense for it, right?
I completely understand what visibility issues might be like, but that does
not apply to win32. I'm not denying anything, I'm just trying to stay on
topic.
> > How would I go about IO completion ports then?
>
> Good question.
To which you ain't got no reply. So, pthreads lack the ability to support NT
IOCP [you can't pthreads-cancel a thread blocked on an IOCP, and they are
not 'portable' anyway]. That means pthreads cannot yet be considered
anything like <cpthreads> by [some] win32 programmers.
S
Slava M. Usov
>
> "Slava M. Usov" wrote:
> >
> > "Alexander Terekhov" <tere...@web.de> wrote in message
> > news:c29b5e33.02052...@posting.google.com...
> > > Hehe. Ok. Ok. Here is a 'hint' for you: *invariants*. Does this help?
> > > ;-)
>
> I guess, I should have said/hinted: *invariants*/*transactions*... ;-) ;-)
Whatever. It is simply incorrect to identify thread safety with exception
safety just because there are overlapping issues.
> http://groups.google.com/groups?selm=38192d73.19559206%40nntp.netcom.ca
> (Subject: Guru of the Week #61: Solution)
>
> "....
> INTRODUCTION
> =======================================================
>
> Exception Safety Recap
> ----------------------
> ....
> Summary
> -------
> ....
> Finally, consider two fundamental implications:
>
> 1. The Transactional Principle: All programming
> operations should be considered as transactions,
> with associated guarantees, and are amenable to this
> new style of ACID transactional analysis. This
> applies regardless of whether exceptions are
> possible or absent.
> ...."
When they are absent, that's just wasting time [yours and CPUs]. Unless
you're going to reuse that code. Even when they are possible, the "I" and
the "D" do not apply.
> http://groups.google.com/groups?selm=3CDBC845.6ACAAC71%40web.de
> (Subject: Re: mutex should be static or not ?)
That whole thing really depends on what and how you do. Please don't tell me
there is exactly one way to do things. From the purist OOP perspective,
locks should certainly be a part of objects because doing otherwise would
violate encapsulation and, worse, leave you a possibility of violating some
object invariants. With multi-object transactions it becomes blurry, but
apparently you could get around by postulating that to perform some
transaction on a set of objects one needs a "transaction" object that does
its locks inside.
From pure performance/efficiency point of view, exactly the opposite thing
would be desirable.
> P.S. Please don't tell me about MS-"interlocked" stuff. ;-)"
How about lock-X machine instructions? Surely they are free from being MS?
S
Alexander Terekhov
"Slava M. Usov" wrote:
>
> "Alexander Terekhov" <tere...@web.de> wrote in message
> news:3CF2446F...@web.de...
> >
> > "Slava M. Usov" wrote:
>
> > > You misunderstood. My question was "why do you not DIRECTLY refer to an
> > > article by your opponent and hope that your readers are qualified enough
> > > to use Google to find your personal views"?
> >
> > That would be just 'too clever' thing to expect, I guess. ;-)
>
> But the opposite thing is not "too clever to expect", right? So much for the
> biased attitudes.
How could 'copy&paste{&edit}' (w/o a link, I mean) be somehow
LESS BIASED ('bandwidth' related considerations aside)?
> > > Another point that I forgot to make
> > > was generally regarding Google URLs as a means to quote a USENET
> > > article. I remember a few years ago everybody was doing the same with
> > > Deja. All of those links and the messages are devoid of context now. A
> > > respectful fate, that.
> >
> > Try this one:
> http://www.deja.com/dnquery.xp?QRY=Slava+comp.programming.threads
>
> That very well might work. However, I remember they had some sort of
> internal IDs and many people got the habit of using them to reference the
> messages. Do you think that will work? Even if they still work, do you think
> that Google will last forever or just any significant time?
Yep. FOREVER. Whoever will take over/replace Google,
they WILL take care of it (make it work). That's so
simple, really.
[...]
> > [...memory visibility...]
> >
> > I'm not sure that you've fully understood it. It (sync/locking)
> > should be done BY EACH THREAD (at least once, in the {special}
> > case of lazy/once-init, for example) in order to work 'portably'...
> > Read that "Java/MP" paper, please.
>
> 'Portable'. Makes no sense for win32 :-) And because you're posting to a
> win32 newsgroup it ought to make sense for it, right?
>
> I completely understand what visibility issues might be like, but that does
> not apply to win32. I'm not denying anything, I'm just trying to stay on
> topic.
How about IA64? Or would you rather dismiss it 'altogether'...
on the grounds of 'Win64 != Win32' <?> ;-)
> > > How would I go about IO completion ports then?
> >
> > Good question.
>
> To which you ain't got no reply. So, pthreads lack the ability to support NT
> IOCP [you can't pthreads-cancel a thread blocked on an IOCP, and they are
> not 'portable' anyway]. That means pthreads cannot yet be considered
> anything like <cpthreads> by [some] win32 programmers.
<cthread>... and yes, win32 folks (and others too) should (IMHO)
simply put a 'proper' amount of pressure (demand) on MS AND TOG
(MS IS A *SILVER* MEMBER OF The Open Group[1]) to standardize
'IOCP'-like thing.
regards,
alexander.
[1] http://www.opengroup.org/overview/members/membership_list.htm
Alexander Terekhov
"Slava M. Usov" wrote:
[...]
> would be desirable.
You mean locking granularity? Yes, these are all 'trade-offs'.
> > P.S. Please don't tell me about MS-"interlocked" stuff. ;-)"
>
> How about lock-X machine instructions? Surely they are free from being MS?
Nah, I'd rather prefer something along the lines of proposed Java's
'atomic classes' with its well defined (acquire/release/both) memory
sync. semantics for all operations. Or, actually, something MORE
specific/tailored for any particular problem... for example:
http://groups.google.com/groups?threadm=3BC8463D.6E23002A%40web.de
("Subject: Lockless/non-blocking ref.counting?", note that unref()
needs to inject write/"release" mem.bars too IF threads could
unref() mutable objects INSIDE synchronized regions for mutation/
updates))
regards,
alexander.
t...@cs.ucr.edu
: Dave Butenhof wrote:
: [...]
:> What's lacking, perhaps, is a requirement that some particular C data size
: is "safe"; that
:> all possible machines ? compilers must support and maintain a definition
: of "a memory
:> location" no larger than some type, such as "int" or "long". The logical
: candidate here
:> would be sig_atomic_t. Though the requirement isn't spelled out, this must
: have the required
:> characteristics in order to be safe for signal handler access as
: specified.
: </quote>
: (but I guess it's just a "candidate" not actual guarantee.. yet? ;-)
Apologies for repeating myself, but the C/C++ language lawyers have
pointe out that sig_atomic_t is guaranteed to be atomic w.r.t. writes
signal handlers. It can be non-atomic for all other writes. (If you
think that's a bit silly, I have to agree, but that's how the
standards read.)
Tom Payne
Jim Rogers
> Apologies for repeating myself, but the C/C++ language lawyers have
> pointe out that sig_atomic_t is guaranteed to be atomic w.r.t. writes
> signal handlers. It can be non-atomic for all other writes. (If you
> think that's a bit silly, I have to agree, but that's how the
> standards read.)
Just to inject a slightly variant point of view I thought I would
discuss how pragma atomic works in Ada.
Ada provides a pragma allowing the application developer to stipulate
that updates to a variable, or all variables of a specified type,
must be performed atomically. This pragma also stipulates that no
temporary copies of the variable are allowed. Every examination of
the variable must examine the variable itself, every modification
of the variable must immediately modify the variable itself.
These pragmas do not require special synchronization constructs.
Instead, they must map to operations that can be performed in a
single machine instruction and cannot be observed (even by another
processor, or at the time of a hardware interrupt) only partially
done. If the programmer applies this pragma to objects or types
for which the target machine does not directly provide atomic
examination and atomic update, a compile-time error message must
marks the pragma as illegal. Note that the use of this
pragma can greatly limit portability.
The difference here between Ada and C++ appears to be that if
the pragma is legal in Ada, then it is legal for all accesses.
Jim Rogers
Hillel Y. Sims
<t...@cs.ucr.edu> wrote in message news:acun9p$n28$2...@glue.ucr.edu...
Yep, I understand that (lack of formal guarantee for anything but async
signal handler access). I guess someone even pointed out that it could
theoretically be accomplished by a special sequence of instructions to
protect the variable access only for async signal handlers, such that it
could be non-atomic for any other access (such as between threads).
Realistically though, it seems the most straightforward way to accomplish
atomic async signal handler safety is via native granularity atomic access,
which would pretty much apply directly to atomic threaded access too (er,
see the Compaq/HP Alpha docs where they talk about granularity and how it
applies simultaneously for async signal handlers and threaded access.. sorry
don't have the link offhand, I posted it recently,
www.openvms.compaq.com/something ;-). Even though it's not currently
formally guaranteed, it seems like it wouldn't be totally outrageous to
require this in future versions of the standard, and would be very useful
for portable multi-threaded programming.
Slava M. Usov
> How could 'copy&paste{&edit}' (w/o a link, I mean) be somehow
> LESS BIASED ('bandwidth' related considerations aside)?
You would by _not_ citing yourself. That's the point. In a discussion as hot
as this one :-) everybody already knows what you _personally_ think. If you
want to stress your point, cite somebody else, directly, not through five
layers of indirection.
> Yep. FOREVER. Whoever will take over/replace Google,
> they WILL take care of it (make it work). That's so
> simple, really.
Provided there IS someone who'll replace.
[...]
> How about IA64? Or would you rather dismiss it 'altogether'...
> on the grounds of 'Win64 != Win32' <?> ;-)
See, it's that simple.
[...]
> <cthread>... and yes, win32 folks (and others too) should (IMHO)
> simply put a 'proper' amount of pressure (demand) on MS AND TOG
> (MS IS A *SILVER* MEMBER OF The Open Group[1]) to standardize
> 'IOCP'-like thing.
How? Can you name, say, five other OSes supporting that?
S
Slava M. Usov
>
> "Slava M. Usov" wrote:
> [...]
> > From pure performance/efficiency point of view, exactly the opposite
> > thing would be desirable.
>
> You mean locking granularity? Yes, these are all 'trade-offs'.
That too.
> > > P.S. Please don't tell me about MS-"interlocked" stuff. ;-)"
> >
> > How about lock-X machine instructions? Surely they are free from being
> > MS?
>
> Nah, I'd rather prefer something along the lines of proposed Java's
> 'atomic classes' with its well defined (acquire/release/both) memory
> sync. semantics for all operations. Or, actually, something MORE
> specific/tailored for any particular problem... for example:
That was not the point. The point was there was nothing inherently "MS" in
that stuff.
S
Alexander Terekhov
"Slava M. Usov" wrote:
[...]
> > <cthread>... and yes, win32 folks (and others too) should (IMHO)
> > simply put a 'proper' amount of pressure (demand) on MS AND TOG
> > (MS IS A *SILVER* MEMBER OF The Open Group[1]) to standardize
> > 'IOCP'-like thing.
>
> How?
How to standardize? Here is the quote:
"Subject: Committee Maintenance Procedures for the Approved Standard
....
The recommended criteria for development of new interfaces to enable
them to be considered for inclusion in a future revision are as follows:
1. There must be a written specification that has undergone a formal
consensus based approval process and is suitable for inclusion.
2. There must be an implementation, preferably a reference implementation.
3. The specification must be "sponsored" by one of three organizations
(The Open Group, IEEE, WG15) within the Austin Group, i.e. they would
support and champion its inclusion.
4. Submitters must provide an outline plan of the editing instructions to
merge the document with the Austin Group specifications, and assistance
to the Austin Group editors as required to complete the merger."
regards,
alexander.
Slava M. Usov
>
> "Slava M. Usov" wrote:
> [...]
> > > <cthread>... and yes, win32 folks (and others too) should (IMHO)
> > > simply put a 'proper' amount of pressure (demand) on MS AND TOG
> > > (MS IS A *SILVER* MEMBER OF The Open Group[1]) to standardize
> > > 'IOCP'-like thing.
> >
> > How?
>
> How to standardize? Here is the quote:
You misunderstood. I thought that question of mine would provide a hint. I
specifically asked about acceptance of that mechanism in the industry. I do
believe that if a sufficient number of the open group members wanted that
mechanism they would have started working on its standardization. That does
not boil down to MS _alone_.
> "Subject: Committee Maintenance Procedures for the Approved Standard
> ....
> The recommended criteria for development of new interfaces to enable
> them to be considered for inclusion in a future revision are as follows:
>
> 1. There must be a written specification that has undergone a formal
> consensus based approval process and is suitable for inclusion.
There is one [win32 reference], but without any consensus, of course.
Although some parts need to be added, like dissociating threads from
completion ports.
> 2. There must be an implementation, preferably a reference
> implementation.
"An implementation" exists; a "reference" one, if I understand the
terminology
correctly, must be open source. I don't believe MS is ever going to do that
:-)
> 3. The specification must be "sponsored" by one of three organizations
> (The Open Group, IEEE, WG15) within the Austin Group, i.e. they would
> support and champion its inclusion.
>
> 4. Submitters must provide an outline plan of the editing instructions to
> merge the document with the Austin Group specifications, and
> assistance to the Austin Group editors as required to complete the
> merger."
These two go after the first two, I believe.
S
Alexander Terekhov
"Slava M. Usov" wrote:
>
> "Alexander Terekhov" <tere...@web.de> wrote in message
> news:3CF384A9...@web.de...
> >
> > "Slava M. Usov" wrote:
> > [...]
> > > > <cthread>... and yes, win32 folks (and others too) should (IMHO)
> > > > simply put a 'proper' amount of pressure (demand) on MS AND TOG
> > > > (MS IS A *SILVER* MEMBER OF The Open Group[1]) to standardize
> > > > 'IOCP'-like thing.
> > >
> > > How?
> >
> > How to standardize? Here is the quote:
>
> You misunderstood. I thought that question of mine would provide a hint.
;-)
> I specifically asked about acceptance of that mechanism in the industry. I do
> believe that if a sufficient number of the open group members wanted that
> mechanism they would have started working on its standardization. That does
> not boil down to MS _alone_.
Well, don't really know anything about 'the industry' as a whole thing,
but Mr.B ;-) once wrote:
http://groups.google.com/groups?selm=3AB60B22.79950AB1%40compaq.com
(Subject: Re: Thread inertia (more readable code than previous posting))
"...
> IMO, you should never be using signals unless there's some reason you can't avoid it, e.g.
> you are stuck with a legacy application or somebody screwed up big time on an api. Take
> for instance, POSIX asynchronous i/o. What were they thinking? It's nearly impossible for
> a signal handler and threads to cleanly interact.
POSIX asynchronous I/O mostly predates the addition of threads to POSIX. You don't really need
to use signals, though the addition of "completion ports" might have made it all easier to work
with. (E.g., Win32, Solaris 8 AIO.)
...."
Well, respected c.p.t. poster also wrote this:
http://groups.google.com/groups?selm=32F5D80A.446B%40zko.dec.com
(Subject: Re: LWP and Thread)
"....
WaitForMultipleObjects can be nice -- but it doesn't have anything
to do with the basic threading model. Queues are easy, and there are so
many ways to use queues that no O/S service is going to be perfect for
every use.
...."
Which, frankly, I personally don't quite follow (w.r.t WaitForMultipleObjects,
I mean) unless, of course, he was merely talking about locking multiple mutexes
via 'one' call -- the ONLY thing I'd probably classify as 'can be nice' w.r.t.
WaitForMultipleObjects... unless I'm just missing and/or misunderstanding
something here (as I quite usually/often do ;-)).
regards,
alexander.
P.S. < from the essay referenced (last link) above >
"....
In the end, your choice of synchronization and signalling models are a
matter of personal choice. I like mine better than yours, and you appear
to like yours better than mine. Cool. That's the way it should be.
...."
I *STRONGLY* DISAGREE!!! ;-) ;-)