Friday, February 19, 2021

Digest for comp.lang.c++@googlegroups.com - 14 updates in 4 topics

Bonita Montero <Bonita.Montero@gmail.com>: Feb 19 11:27PM +0100

> My below powerful inventions of LW_Fast_RWLockX and Fast_RWLockX that are two powerful scalable RWLocks that are FIFO fair
 
RW-locks are never fair.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 19 02:48PM -0800

On 2/19/2021 2:27 PM, Bonita Montero wrote:
>> My below powerful inventions of LW_Fast_RWLockX and Fast_RWLockX that
>> are two powerful scalable RWLocks that are FIFO fair
 
> RW-locks are never fair.
 
There are implementations that can be starvation free.
Bonita Montero <Bonita.Montero@gmail.com>: Feb 20 12:01AM +0100

>>> are two powerful scalable RWLocks that are FIFO fair
 
>> RW-locks are never fair.
 
> There are implementations that can be starvation free.
 
No, impossible. Readers can hold the lock as long as they
want and starve out writers. And writers could do the same.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 19 03:17PM -0800

On 2/19/2021 3:01 PM, Bonita Montero wrote:
 
>> There are implementations that can be starvation free.
 
> No, impossible. Readers can hold the lock as long as they
> want and starve out writers. And writers could do the same.
 
Ummm... I am not sure what you mean here. The type of starvation I am
talking about is when reader activity is so frequent that writers just
can't seem to get in. Even if the reader critical sections are short.
Every time a writer wants to get in, several readers jump in line. Its
all about reader or writer priority, a lot of rwmutex impls have that
flaw. Sure a reader can hold the lock for an hour, okay. Well, writers
cannot get in for an hour. That's perfectly normal. This is not the same
type of starvation I am referring to...
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Feb 18 08:47PM -0500

Is it possible to define Standard C++ Library Container Types UM, OM and L such
that:
 
- UM is an std::unordered_map with key_type int and mapped_type iterator to OM
- OM is an std::map with key_type int and mapped_type L
- L is an std::list of iterators to UM
 
?
 
TIA,
-Pavel.
Bonita Montero <Bonita.Montero@gmail.com>: Feb 19 02:56PM +0100

Am 19.02.2021 um 02:47 schrieb Pavel:
> - UM is an std::unordered_map with key_type int and mapped_type iterator to OM
> - OM is an std::map with key_type int and mapped_type L
> - L is an std::list of iterators to UM
 
#include <unordered_map>
#include <map>
#include <list>
 
template<typename L>
using OM = std::map<int, L>;
template<typename L>
using UM = std::unordered_map<int, typename OM<L>::iterator>;
template<typename T>
using L = std::list<typename OM<T>::iterator>;
Ralf Goertz <me@myprovider.invalid>: Feb 19 05:13PM +0100

Am Fri, 19 Feb 2021 14:56:43 +0100
> using UM = std::unordered_map<int, typename OM<L>::iterator>;
> template<typename T>
> using L = std::list<typename OM<T>::iterator>;
 
And how would you instantiate those? How do I declare the three
variables om, um and l? (I had tried something similar but hadn't
managed to get it compiled.)
Bonita Montero <Bonita.Montero@gmail.com>: Feb 19 05:44PM +0100

Am 19.02.2021 um 17:13 schrieb Ralf Goertz:
>> using UM = std::unordered_map<int, typename OM<L>::iterator>;
>> template<typename T>
>> using L = std::list<typename OM<T>::iterator>;
 
f.e.
L<int> li;
 
mickspud@potatofield.co.uk: Feb 19 10:23AM

On Wed, 17 Feb 2021 13:26:24 -0500
>On 2/17/21 12:12 PM, mickspud@potatofield.co.uk wrote:
>> That int looks nonaligned to me.
 
>For the reasons given above, on an implementation which can have the
 
So one minute you're saying it CANNOT happen, next minute its "oh, except
on architectures where it can."
 
Whatever mate.
 
>implementation of C? If so, which implementation is it, and what is the
>target platform? In particular, what are the values of
>_Alignof(uint32_t), sizeof(uint32_t*), and sizeof(char*)?
 
 
All irrelevant. You said - and I quote - it CANNOT happen. Well it can. End of.
mickspud@potatofield.co.uk: Feb 19 10:24AM

On Wed, 17 Feb 2021 11:27:56 -0800
 
>James was talking about "a pointer type that can only represent
>positions at the beginning of a word", something that doesn't exist on
>the implementation you're using.
 
He said it cannot happen. He didn't say it cannot on certain architectures,
he said it cannot, full stop. Well it can.
 
>On the implementation you're using, a uint32_t* pointer value *can*
>point to an odd address, and such a pointer can be dereferenced
>successfully.
 
You don't say.
James Kuyper <jameskuyper@alumni.caltech.edu>: Feb 19 08:57AM -0500


>> For the reasons given above, on an implementation which can have the
 
> So one minute you're saying it CANNOT happen, next minute its "oh, except
> on architectures where it can."
 
What I said was:
 
"Conversion of a pointer that doesn't point at the beginning of a word
to a pointer type that can only represent positions at the beginning of
a word CANNOT result in a pointer to the same location.".
 
That is absolutely true, without exceptions: if the pointer type is only
capable of representing positions at the beginning of a word, it cannot
represent the same position as a pointer that doesn't point to the
beginning of the word. Therefore, conversion of such a pointer to such a
type cannot result in a pointer that points at the same location.
 
On implementations where every pointer type can represent any position
in memory, the statement isn't false - the conditions under which it
would apply simply cannot occur.
 
And I was very clear at every stage of this discussion that I was
talking about behavior which can vary from one implementation to
another. Relevant quotes:
 
"If a compiler performs an optimization ..."
"... has undefined behavior ..."
"Most C compilers do ..."
"It's not guaranteed to, ..."
"Implementations are allowed ..."
"... there have been implementations ..."
"... on an implementation where ..."
"... the implementation defines ..."
"... on implementations where ..."
"... on an implementation which ..."
 
I've tried my best to make it crystal clear that I was talking about
behavior which can vary between one implementation and another. If
there's anything I could have written differently to prevent you from
getting confused about that aspect of what I was saying, please let me
know how you think I should have re-worded it.
James Kuyper <jameskuyper@alumni.caltech.edu>: Feb 19 09:03AM -0500

>> the implementation you're using.
 
> He said it cannot happen. He didn't say it cannot on certain architectures,
> he said it cannot, full stop. Well it can.
 
Yes, I was quite clear about it being implementation-dependent. I said
"a pointer type which can only represent positions at the beginning of a
word". I made it quite clear that whether or not there are any such
types is something that depends upon the implementation.
mickspud@potatofield.co.uk: Feb 19 02:14PM

On Fri, 19 Feb 2021 09:03:20 -0500
>"a pointer type which can only represent positions at the beginning of a
>word". I made it quite clear that whether or not there are any such
>types is something that depends upon the implementation.
 
In other words its not part of the standard which is the position you were
arguing from.
Cholo Lennon <chololennon@hotmail.com>: Feb 19 01:15AM -0300

On 2/11/21 2:13 PM, David Brown wrote:
> are atomic and safe to do in threaded code. The GIL can therefore make
> it easier to write thread-safe code in Python, because you don't need
> explicit locks for many uses of shared state.
 
Yes, you're right, a lot of code rely on GIL behavior. That is why they
still haven't figured out how to remove it painlessly. For sure it will
never be removed, unless a new incompatible version (4 maybe) take care
of it.
 
Years ago, in order to overcome the multi-thread limitations of Python,
I managed to run my load simulator (for a specific telecommunication
protocol) in Jython 2.7 without any problem. The improve in performance
was huge. It's known that that particular implementation of Python
doesn't have a GIL because of the underlying JVM.
Of course it worked for me, but I don't know how many Python 2.7
applications can run under Jython, not only because they rely on GIL,
but also because they use a lot libraries that are natively implemented
(which in turn, can also rely on GIL). Unfortunately Jython 3.x does not
exist yet.
 
Regards.
 
--
Cholo Lennon
Bs.As.
ARG
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)