Wednesday, February 6, 2019

Digest for comp.lang.c++@googlegroups.com - 8 updates in 3 topics

ahmetcanun@gmail.com: Feb 06 01:49AM -0800

Hi,
 
I want to define services inside proto messages as below.
 
Example of a proto file.
 
syntax = "proto2";
 
message Sample {
//
}
 
message Example {
//
service Service {
rpc someMethod(Sample) returns Sample;
}
}
 
So I can refer to that rpc as 'Example.Service.someMethod'.
 
There may be another services, methods with the same name as 'AnotherExample.Service.somMethod' nested in other messages.
 
This provides a logical relationship between
messages and rpc's for me.
 
Protoc does not support this, proto file fails to compile.
 
How can I achieve this?
mvorbrodt@gmail.com: Feb 05 03:38PM -0800

On Tuesday, February 5, 2019 at 6:20:55 PM UTC-5, Chris M. Thomasson wrote:
> getting older. The ability to skip a lot of calls into to the
> "slow_semaphore" is very beneficial.
 
> ;^)
 
you're very welcome :) thank you for sharing it with me. could you maybe comment on my blog please and give us an explanation of how exactly it work, and why the specific values for memory model?
mvorbrodt@gmail.com: Feb 05 03:40PM -0800

On Tuesday, February 5, 2019 at 6:20:55 PM UTC-5, Chris M. Thomasson wrote:
> getting older. The ability to skip a lot of calls into to the
> "slow_semaphore" is very beneficial.
 
> ;^)
 
See here: https://www.reddit.com/r/cpp/comments/anhnw3/fast_semaphore/
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Feb 05 04:01PM -0800

>> "slow_semaphore" is very beneficial.
 
>> ;^)
 
> See here: https://www.reddit.com/r/cpp/comments/anhnw3/fast_semaphore/
 
Before I comment there, the fences in the fast_semaphore are exactly
what is needed. Period. We _cannot_ get rid if them. End of story. I
will provide more into later on today or tomorrow.
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Feb 05 04:07PM -0800

On 2/5/2019 4:01 PM, Chris M. Thomasson wrote:
 
> Before I comment there, the fences in the fast_semaphore are exactly
> what is needed. Period. We _cannot_ get rid if them. End of story. I
> will provide more into later on today or tomorrow.
 
Actually, this is a good example. If we remove any of the fences, or
even weaken them, then the algorithm does _not_ work at all! The fences
enforce the acquire/release relationship between the wait/post functions
where wait is acquire, and post is release. The code has the position of
the membars in the exact correct position. The release is _before_ we do
anything in post. The acquire is _after_ we do everything in wait. If
the position of the standalone fences is changed, then the algorithm
will bite the dust.
 
Joe Seighs excellent algorithm is 100% correct, and the implementation I
showed you is 100% correct, period.
 
Will go into more detail today or tomorrow.
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Feb 05 04:17PM -0800

On 2/5/2019 4:07 PM, Chris M. Thomasson wrote:
 
> Joe Seighs excellent algorithm is 100% correct, and the implementation I
> showed you is 100% correct, period.
 
> Will go into more detail today or tomorrow.
 
Ahhh, the following interesting discussion might be of interest wrt the
standalone fences:
 
https://groups.google.com/d/topic/lock-free/A1nzcMBGRzU/discussion
(read all...)
 
Another reason why I like standalone fences is that we can place them in
the _exact_ places they need to be. The other style of fences are
directly integrated into the std::atomic operations themselves. However,
they can be limited wrt flexibility. Take the following code into
account: It flushes all of the nodes from an atomic stack in a single
atomic operation:
_____________________________
// try to flush all of our nodes
node* flush()
{
node* n = m_head.exchange(nullptr, mb_relaxed);
 
if (n)
{
mb_fence(mb_acquire);
}
 
return n;
}
_____________________________
 
Notice how this specialized 100% standard membar setup is _impossible_
to accomplish with the integrated membars? Standalone fences are what I
am basically used to working with way back on the SPARC.
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Feb 05 11:24PM -0800

> my blog entry about fast c++ semaphore implementation: http://blog.vorbrodt.me/?p=495
 
Fwiw, this is called a benaphore:
 
https://en.wikipedia.org/wiki/Futex#BENAPHORE
 
I am not sure if Joe Seigh helped invent it or not. He was working at
IBM in the 80's and 90's. Fwiw, here is a patent for an interesting
reference counting algorithm invented by Joe:
 
https://patents.google.com/patent/US5295262
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Feb 05 04:23PM -0800

On 2/5/2019 1:35 AM, Juha Nieminen wrote:
>> is called a lot, then this type of racy check might be perfectly fine.
 
> Making the variable atomic only makes sure that reading and writing the
> variable itself concurrently won't result in garbage values.
 
It also prevents undefined behavior wrt a raw data-race.
 
 
> container is not empty, when in reality it is; it's just that the
> routine that emptied the container was just about to zero the size
> variable when that other thread read it.
 
Fair enough. Even if the empty condition returns a coherent answer, it
still unlocks the mutex. So, the next time we check it, the empty
condition might be different. Fwiw, I usually only use these types of
empty function calls for statistics. Just to see how many times the
queue is empty within a certain time frame. This type of data can be
used for heuristics to alter server state, build graphs or whatever...
 
 
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)