To anybody at Microsoft who cares... :)
SenderX
description" of the InterlockedXXX API's memory visibility semantics?
I think you are going for the straight forward method of acquire/release,
but your docs need to be tightened up. For one, does
InterlockedCompareExchangeAcquire/Release execute the membar upon cas
failure, on non-tso CPU's? You are forcing programmers to disassemble your
atomic-ops to try to ease their minds. I know that acquire/release has
basically the same memory visibility rules that pthread_mutex_lock/unlock
has, but you still need to document "exactly what your acquire/release
semantics are", and give detailed description on how they "apply to your
interlocked API"...
MSDN would be a great place for this... Put it under something like:
"The Microsoft Memory Visibility Standard: Acquire/Release/Full"
:O
P.S.
I also wouldn't hurt to document how acquire/release "applies to all of your
sync primitives"...
;)
Sten Westerback
code anyway ... and if you are not happy with the way they work
then make your own.... or even use another OS. :p
- Sten
"SenderX" <x...@xxx.com> wrote in message
news:f0EEc.3478$MB3.1944@attbi_s04...
Alf P. Steinbach
* Sten Westerback:
>
> "SenderX" <x...@xxx.com> wrote in message
> news:f0EEc.3478$MB3.1944@attbi_s04...
> > Do you guys have any idea when/if you are going to give a "detailed
> > description" of the InterlockedXXX API's memory visibility semantics?
> >
> > I think you are going for the straight forward method of acquire/release,
> > but your docs need to be tightened up. For one, does
> > InterlockedCompareExchangeAcquire/Release execute the membar upon cas
> > failure, on non-tso CPU's? You are forcing programmers to disassemble your
> > atomic-ops to try to ease their minds. I know that acquire/release has
> > basically the same memory visibility rules that pthread_mutex_lock/unlock
> > has, but you still need to document "exactly what your acquire/release
> > semantics are", and give detailed description on how they "apply to your
> > interlocked API"...
> >
> > MSDN would be a great place for this... Put it under something like:
> >
> > "The Microsoft Memory Visibility Standard: Acquire/Release/Full"
> > :O
> >
> > P.S.
> > I also wouldn't hurt to document how acquire/release "applies to all of
> > your sync primitives"... ;)
>
That should be obvious to anyone in a position to comment. If it's not
obvious to you then you don't know enough to comment. So why do you?
Also, what are those quotes doing in there?
It seems like an attempt at insinuation; perphaps that's what your
comment is really about.
> You won't be able to modify the code anyway ...
Why do you think anyone except _you_ have entertained that braindead
idea?
Also, it seems like yet another attempt at insinuation.
Perphaps that's what your comment is really about.
> and if you are not happy with the way they work then make your
> own.... or even use another OS. :p
Idiot.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Kip Warner
lol, that is the most creative troll I have ever seen.
Kip
SenderX
> > InterlockedCompareExchangeAcquire/Release execute the membar upon cas
> > failure, on non-tso CPU's?
> Why do you "need" that detail?
Because, if you don't know for sure that the barrier is executed upon cas
failure, how can you use the data returned without worrying if the thread
has a consistent view of it?
The docs need to be a bit more detailed...
Brandon
> * Sten Westerback:
[SNIP]
> > Why do you "need" that detail?
>
> That should be obvious to anyone in a position to comment. If it's not
> obvious to you then you don't know enough to comment. So why do you?
[SNIP]
> > You won't be able to modify the code anyway ...
>
> Why do you think anyone except _you_ have entertained that braindead
> idea?
If it's not obvious to you then you don't know enough to comment. ;)
Sorry - I couldn't resist. Keep up the good work though. I'm sure
the Newsgroup Police appreciate your efforts.
Alf P. Steinbach
Tell that to Sten Westerback.
Ziv Caspi
Multiprocessor Considerations for Kernel-Mode Drivers
http://www.microsoft.com/whdc/driver/kernel/MP_issues.mspx
Ziv Caspi
"SenderX" <x...@xxx.com> wrote in message
news:f0EEc.3478$MB3.1944@attbi_s04...
Alexander Terekhov
Ziv Caspi wrote:
>
> Does this help?
>
> Multiprocessor Considerations for Kernel-Mode Drivers
> http://www.microsoft.com/whdc/driver/kernel/MP_issues.mspx
You mean totally idiotic "ReleaseLock()"? Well, it does sorta help,
just not the way you expect it to help, I'm afraid. ;-)
Uhmm, just in case...
http://groups.google.de/groups?selm=41C97341.10A67159%40web.de
http://groups.google.de/groups?selm=41CAF4A6.21D1E051%40web.de
Hth.
regards,
alexander.
Joseph Seigh
You want to have some sort of generic memory barriers around just
in case there's a situation that the other synchronization primatives
can't handle or for when you want to create a new synchronization
primative and don't want to deal with platform specific memory
barriers.
20 versions of memory barrier is overkill. Plus you have the problem
that on most platforms the implementation will be stronger than the
membar definition and mislead the user into thinking otherwise. So
a #Load/Store might be efficient on sparc, but it's going to be
MFENCE on ia32/64. The programmer would be better off realizing
this and attempting another solution.
And you have the problem that people may start using these to
define synchronization semantices in terms of a meta memory
model that does not exist on any hardware.
Joe Seigh
zi...@netvision.net.il
Alexander Terekhov wrote:
> You mean totally idiotic "ReleaseLock()"? Well, it does sorta help,
> just not the way you expect it to help, I'm afraid. ;-)
>
> Uhmm, just in case...
>
> http://groups.google.de/groups?selm=41C97341.10A67159%40web.de
> http://groups.google.de/groups?selm=41CAF4A6.21D1E051%40web.de
>
> Hth.
No, it doesn't really help. If you want to have a meaningful
conversation, please try to use full sentences rather than
just include links to posts with more links, which are impossible
for some (at least one) to follow.
And losing the idiotic/moronic/braindead attributions would
also greatly help.
Ziv Caspi
Jussi Jumppanen
> No, it doesn't really help. If you want to have a meaningful
> conversation,
Why are you assuming he is interested in conversing with you?
> please try to use full sentences rather than just include
> links to posts with more links,
He is posting this information free of charge. It is up to
you what you do with this information.
> which are impossible for some (at least one) to follow.
So is that his problem or yours?
> And losing the idiotic/moronic/braindead attributions
> would also greatly help.
Are you offering this as example of the type of conversation
you are looking for?
Jussi Jumppanen
Author of: Zeus for Windows (New version 3.93 out now)
"The C/C++, Cobol, Java, HTML, Python, PHP, Perl programmer's editor"
Home Page: http://www.zeusedit.com
zi...@netvision.net.il
> zi...@netvision.net.il wrote:
>
> > No, it doesn't really help. If you want to have a meaningful
> > conversation,
>
> Why are you assuming he is interested in conversing with you?
Beause he made his post in reply to my own.
>
> > please try to use full sentences rather than just include
> > links to posts with more links,
>
> He is posting this information free of charge.
So do I.
> It is up to
> you what you do with this information.
Indeed; for example, I chose to reply.
> > which are impossible for some (at least one) to follow.
>
> So is that his problem or yours?
Communication Theory 101: successful communication is measured
at the receiving end.
It's neither his problem nor mine, BTW. I'm rather certain
both of us would continue happily with our lives regardless.
> > And losing the idiotic/moronic/braindead attributions
> > would also greatly help.
>
> Are you offering this as example of the type of conversation
> you are looking for?
Of course. My post was constructing, indicating both
what I think is wrong and how to correct it.
_This_ post (as well as yours) isn't.
Ziv Caspi
Alexander Terekhov
zi...@netvision.net.il wrote:
[...]
> how to correct it.
The mess you have is flawed beyond correction and needs to be
eliminated entirely.
http://groups.google.de/groups?threadm=3F7AAF52.61390EA%40web.de
http://groups.google.de/groups?threadm=40E44603.73361545%40web.de
regards,
alexander.
Ziv Caspi
news:41E5250C...@web.de...
Tail-call to my initial response to your post....