atomic pointers C11, Pelles C compiler...

[Chris M. Thomasson]

here is my main question:

https://forum.pellesc.de/index.php?topic=7311.0

The content of the link above:
********************************
I am not sure why atomic_is_lock_free is returning false for a pointer
type, and true for an uintptr_t.

Try running this program:
____________________
#include <stdio.h>
#include <stdint.h>
#include <stdatomic.h>


int main(void)
{
_Atomic void* ptr = NULL;

printf("atomic_is_lock_free(void*):%s\n",
atomic_is_lock_free(&ptr) ? "true" : "false");

_Atomic uintptr_t uptr = 0;

printf("atomic_is_lock_free(uintptr_t):%s\n",
atomic_is_lock_free(&uptr) ? "true" : "false");

return 0;
}
____________________

I get:

atomic_is_lock_free(void*):(false)
atomic_is_lock_free(uintptr_t):(true)

The void pointer should be atomic wrt the _Atomic keyword. I must be
missing something here.

Do I need to cast the pointers to and from uintptr_t?

Thanks.
********************************

Any thoughts?

[James R. Kuyper]

The standard doesn't guarantee that any type other than atomic_flag is
lock-free (7.17.8p3). That's the reason for the ATOMIC_*_LOCK_FREE
macros and the atomic_is_lock_free() generic function.

To what value does ATOMIC_POINTER_LOCK_FREE (#defined in <stdatomic.h>)
expand for the implementation you're using?

> Do I need to cast the pointers to and from uintptr_t?

Apparently. However, keep in mind that there's no guarantee that
uintptr_t is lock-free, either.
Note: in any situation where it's important that uptr be lock_free, you
will not be able to convert it to a pointer and dereference the pointer
unless the pointed-at object is also lock-free.

[Chris M. Thomasson]

Here it is:
________________________________

/* macros */

/* a value of 0 indicates that the type is never lock-free;
* a value of 1 indicates that the type is sometimes lock-free;
* a value of 2 indicates that the type is always lock-free
*/
#define ATOMIC_BOOL_LOCK_FREE 2
#define ATOMIC_CHAR_LOCK_FREE 2
#define ATOMIC_CHAR16_T_LOCK_FREE 2
#define ATOMIC_CHAR32_T_LOCK_FREE 2
#define ATOMIC_WCHAR_T_LOCK_FREE 2
#define ATOMIC_SHORT_LOCK_FREE 2
#define ATOMIC_INT_LOCK_FREE 2
#define ATOMIC_LONG_LOCK_FREE 2
#define ATOMIC_LLONG_LOCK_FREE 2
#define ATOMIC_POINTER_LOCK_FREE 2
________________________________

It is always lock-free. ;^)


I now know why my previous code said the void pointer was not lock-free.
Received some very informative responses over on the Pelles C forum.
Here is a part of the most relevant one:
_________________________
Well, the first point is the declaration of the void pointer that is
wrong. It should not be:

_Atomic void* ptr = NULL;

But

void * _Atomic ptr = NULL;

The last one will give you the correct response.

Remember that the definitions in C must be read from left to right, in
the second case we have that ptr is an atomic variable that holds a
pointer to void.
_________________________

https://forum.pellesc.de/index.php?topic=7311.0
(read all...)

Now, void* is always returning 2 from atomic_is_lock_free.

I just wanted a 1 or a 2. Was really surprised to see 0, or false. Also,
if you notice, they found a possible bug in the compiler in the thread I
started.

>> Do I need to cast the pointers to and from uintptr_t?
>
> Apparently. However, keep in mind that there's no guarantee that
> uintptr_t is lock-free, either.
> Note: in any situation where it's important that uptr be lock_free, you
> will not be able to convert it to a pointer and dereference the pointer
> unless the pointed-at object is also lock-free.

They instructed me on how to get the void* pointer wrt
atomic_is_lock_free to report true. However, they most likely found a
bug in atomic_store. It has to be in others functions like
atomic_exchange and friends. Still cannot get DWCAS anchors to pass
atomic_is_lock_free.

Humm...

[Steven Petruzzellis]

BTW, I've already proved that his use of "herd" to describe true advocates is insulting, since he's likening them to lower life forms. So why the task to view data via an automated phone system in a super computer system? Predictably, Scott 'The Shill' Lurndal didn't define this as part of his inevitably continually changing 'needs' <whatever>. Time to blame the lack of many eyes!

Awhile back I did work on and showed some Swift for the front end (only works on high end systems) which is the only thing you can do when trying to avoid Scott 'The Shill' Lurndal's dishonest crap while reading with Google Groups.

That lame duck update system failed over and over again.

--
Best CMS Solution of 2017
https://youtu.be/BUjnZhKk1Bg
https://youtu.be/E3m_i-x92D0
Jonas Eklundh

[Chris M. Thomasson]

On 4/13/2018 6:13 AM, James R. Kuyper wrote:

> On 04/13/2018 01:12 AM, Chris M. Thomasson wrote:
>> here is my main question:
>>
>> https://forum.pellesc.de/index.php?topic=7311.0

[...]

Fwiw, here is my current response:

https://forum.pellesc.de/index.php?topic=7311.msg27764#msg27764
___________________
Wrt to my DWCAS proxy collector, I need a pointer and an intptr_t to be
at least lock-free.
________________________
struct ct_proxy_dwcas
{
struct ct_proxy_node* node;
intptr_t count;
};
________________________

We can do this in 32-bit systems with cmpxchg8b. We can do this in
64-bit systems with cmpxchg16b.

https://www.felixcloutier.com/x86/CMPXCHG8B:CMPXCHG16B.html

We can do this in IBM wrt the Principals of Operation for a lock-free
stack and ABA counter:

http://publibfp.dhe.ibm.com/epubs/pdf/dz9zr009.pdf

Take a look at Appendix A-50 Free Pool Manipulation.

Also, what about, 32-bit x86:
________________________
AC_SYS_APIEXPORT
int AC_CDECL
np_ac_i686_atomic_dwcas_fence
( void*,
void*,
const void* );


np_ac_i686_atomic_dwcas_fence PROC
push esi
push ebx
mov esi, [esp + 16]
mov eax, [esi]
mov edx, [esi + 4]
mov esi, [esp + 20]
mov ebx, [esi]
mov ecx, [esi + 4]
mov esi, [esp + 12]
lock cmpxchg8b qword ptr [esi]
jne np_ac_i686_atomic_dwcas_fence_fail
xor eax, eax
pop ebx
pop esi
ret

np_ac_i686_atomic_dwcas_fence_fail:
mov esi, [esp + 16]
mov [esi + 0], eax;
mov [esi + 4], edx;
mov eax, 1
pop ebx
pop esi
ret
np_ac_i686_atomic_dwcas_fence ENDP
________________________

Double Width Compare and Swap (DWCAS) should be on C11 and C++11 when
the architecture supports it.

I know that C++11 totally supports lock-free DWCAS on architectures that
provide it, works like a charm. Read:

https://groups.google.com/forum/#!original/lock-free/X3fuuXknQF0/Ho0H1iJgmrQJ

Why is atomic_is_lock_free wrt a pointer to a double width structure
giving me false, when it totally works lock-free on the architecture itself?
___________________

[Steven Petruzzellis]

On and on. You're again trying to push your ego when you have no skill. You're the village idiot and your many idiotic tasks show this. So, yeah, I buy into my own fiction, fully knowing it's fake, because it makes me reconsider my code, improving it. His desire is to see owl chased away by nonstop flooding. And hey, that could or could not... you know what I mean.

-
Puppy Videos!
http://www.5z8.info/--INITIATE-CREDIT-CARD-XFER--_k7s1jt_inject_worm
https://prescottareapsychopaths.wordpress.com/shawn-ulman-psychopath
Jonas Eklundh Communication AB

[supe...@casperkitty.com]

On Friday, April 13, 2018 at 8:14:08 AM UTC-5, James R. Kuyper wrote:
> The standard doesn't guarantee that any type other than atomic_flag is
> lock-free (7.17.8p3). That's the reason for the ATOMIC_*_LOCK_FREE
> macros and the atomic_is_lock_free() generic function.

I wonder what the purpose of such macros is? I can imagine many situations
where a program would need to refuse to run on any implementation where
atomic operations would be guaranteed to deadlock in case of contention,
and even those where they might do so, but far fewer that would need to
be limited to implementations where livelock was provably impossible.
Unfortunately, the only quality-of-implementation test I know would require
that implementations that can't prove live-lock is impossible [even if
there would be no way for it to occur in most programs] lump themselves with
those where atomic operations couldn't possibly work in case of contention.

How many programs should allow themselves to run on implementations where
operations on an atomic object would often be guaranteed to deadlock if
there is any contention, or refuse to run on implementations where livelock
would be possible under contrived conditions, but would not be a concern for
most practical programs?

[Scott Lurndal]

supe...@casperkitty.com writes:
>On Friday, April 13, 2018 at 8:14:08 AM UTC-5, James R. Kuyper wrote:
>> The standard doesn't guarantee that any type other than atomic_flag is
>> lock-free (7.17.8p3). That's the reason for the ATOMIC_*_LOCK_FREE
>> macros and the atomic_is_lock_free() generic function.

The reason for this is simply that there existed processor architectures
whose sole atomic primitive was something like load-linked/store-conditional (MIPS)
or load-exclusive/store-exclusive (ARM). It was only with V8.1 that ARM introduced
atomic arithmetic operations to the aarch64 instruction set.

Thus, on such machines, atomics other than test-and-set would require a
separate lock to ensure atomicity.

>
>I wonder what the purpose of such macros is?

See above.

[Robert Wessel]

On Mon, 16 Apr 2018 08:20:31 -0700 (PDT), supe...@casperkitty.com
wrote:

That's not what lock free means. If the operation is tagged as lock
free it means it'll be performed without using a mutex or similar
synchronization device.

[supe...@casperkitty.com]

How can one distinguish between a conforming implementation that uses
ll/sx for some particular type from one that uses an external locking
mechanism, *given that neither kind of implementation is lock-free*?
Many implementations are obstruction-free but not lock-free, and many
programs require obstruction-freedom but not lock-freedom.

If a program requires obstruction-freedom but not lock-freedom, is there
any way that it can be compatible with a conforming implementation that
only offers the former, while rejecting implementations can't are not
obstruction-free?

[supe...@casperkitty.com]

On Monday, April 16, 2018 at 11:19:24 AM UTC-5, robert...@yahoo.com wrote:
> That's not what lock free means. If the operation is tagged as lock
> free it means it'll be performed without using a mutex or similar
> synchronization device.

Is the definition of "lock-free" given on Wikipedia's "Non-blocking
algorithms" page erroneous?

I could easily believe that the definition given there is not what the
authors of the Standard *intended* the macro to indicate, but when I looked
in the Standard for any definition of "lock free" I didn't find one.

On some platforms, two threads running a minimal-length LL/CS loops may
live-lock, but a more complicated (and slower) implementation may be able
to guarantee forward progress in all cases. In most use cases, the simpler
implementation would be superior in every regard, since outside circumstances
would never allow two threads to remain live-locked for very long. On the
other hand, some use cases would require that implementations put in the
extra effort to genuinely satisfy the definition "lock-free" given on
Wikipedia.

[james...@verizon.net]

On Monday, April 16, 2018 at 12:32:52 PM UTC-4, supe...@casperkitty.com wrote:
> On Monday, April 16, 2018 at 11:19:24 AM UTC-5, robert...@yahoo.com wrote:
> > That's not what lock free means. If the operation is tagged as lock
> > free it means it'll be performed without using a mutex or similar
> > synchronization device.
>
> Is the definition of "lock-free" given on Wikipedia's "Non-blocking
> algorithms" page erroneous?

It might or not be erroneous, but it is irrelevant. The only thing that
the C standard actually says about what lock-free means (as opposed to
what is says about how to determine if an object is lock-free) is in
connection with signal handlers:
"When the processing of the abstract machine is interrupted by receipt
of a signal, the values of objects that are neither lock-free atomic
objects nor of type volatile sig_atomic_t are unspecified, as is the
state of the floating-point environment. The value of any object
modified by the handler that is neither a lock-free atomic object nor of
type volatile sig_atomic_t becomes indeterminate when the handler exits,
as does the state of the floating-point environment if it is modified by
the handler and not restored to its original state."

If you're inferring anything about what lock-free means in a C context,
other than what is implied by that paragraph, you're going outside the
domain of the C standard.

> I could easily believe that the definition given there is not what the
> authors of the Standard *intended* the macro to indicate, but when I looked
> in the Standard for any definition of "lock free" I didn't find one.

It's only defined indirectly, by what the standard says about lock-free
objects (cited above).

> On some platforms, two threads running a minimal-length LL/CS loops may

In particular, lock-free is not defined as having any specific
implications with respect to threads. "atomic" is inextricably connected
to "lock-free" as far as the C standard is concerned. "atomic" has lots
of thread-related implications - but "lock-free" itself does not.

[supe...@casperkitty.com]

On Monday, April 16, 2018 at 12:50:41 PM UTC-5, james...@verizon.net wrote:
> On Monday, April 16, 2018 at 12:32:52 PM UTC-4, supe...@casperkitty.com wrote:
> > On Monday, April 16, 2018 at 11:19:24 AM UTC-5, robert...@yahoo.com wrote:
> > > That's not what lock free means. If the operation is tagged as lock
> > > free it means it'll be performed without using a mutex or similar
> > > synchronization device.
> >
> > Is the definition of "lock-free" given on Wikipedia's "Non-blocking
> > algorithms" page erroneous?
>
> It might or not be erroneous, but it is irrelevant. The only thing that
> the C standard actually says about what lock-free means (as opposed to
> what is says about how to determine if an object is lock-free) is in
> connection with signal handlers:
> "When the processing of the abstract machine is interrupted by receipt
> of a signal, the values of objects that are neither lock-free atomic
> objects nor of type volatile sig_atomic_t are unspecified, as is the
> state of the floating-point environment. The value of any object
> modified by the handler that is neither a lock-free atomic object nor of
> type volatile sig_atomic_t becomes indeterminate when the handler exits,
> as does the state of the floating-point environment if it is modified by
> the handler and not restored to its original state."

Only a tiny fraction of the programs that need to use atomic primitives use
asynchronous signals that are configured with the "signal" library function
as the sole means by which different execution contexts interact. In many
cases:

1. Functions will need to interact with objects that are also used
asynchronously in other execution contexts whose specifics the
functions may not know--nor have any particular reason to care--
about.

2. Platforms will define means via which such functions can ensure
that actions performed by some function interact predictably with
those performed in other contexts, without the function having to
know or care about the specifics of those other functions.

As such, it would be useful to have a standardized means via which
implementations targeting platforms that satisfy #2 can meet the needs of
programs requiring #1, without requiring that those implementations provide
any particular means by which outside execution contexts might be brought
into existence. While the code that instantiates such contexts would likely
need to be non-portable, that shouldn't be necessary for code that merely
needs to interact with them safely.

If atomic objects are only accessed in a signal() handlers along with a
single main-line task, then it would be possible for an implementation to
wrap all signal handlers in code that would allow objects of arbitrary type
to behave in lock-free atomic fashion, and there would be no reason why
all implementations couldn't support "lock-free" atomics of all types.
I'm not sure how often such things would be useful, however, compared with
atomic types that interact predictably with other execution contexts.

[Robert Wessel]

On Mon, 16 Apr 2018 09:32:42 -0700 (PDT), supe...@casperkitty.com
wrote:

>On Monday, April 16, 2018 at 11:19:24 AM UTC-5, robert...@yahoo.com wrote:
>> That's not what lock free means. If the operation is tagged as lock
>> free it means it'll be performed without using a mutex or similar
>> synchronization device.
>
>Is the definition of "lock-free" given on Wikipedia's "Non-blocking
>algorithms" page erroneous?

No, but it is a bit more comprehensively defined than the usage in the
standard.

>I could easily believe that the definition given there is not what the
>authors of the Standard *intended* the macro to indicate, but when I looked
>in the Standard for any definition of "lock free" I didn't find one.
>
>On some platforms, two threads running a minimal-length LL/CS loops may
>live-lock, but a more complicated (and slower) implementation may be able
>to guarantee forward progress in all cases. In most use cases, the simpler
>implementation would be superior in every regard, since outside circumstances
>would never allow two threads to remain live-locked for very long. On the
>other hand, some use cases would require that implementations put in the
>extra effort to genuinely satisfy the definition "lock-free" given on
>Wikipedia.

These are only for atomics, and livelock can't occur for single word
updates for properly implemented LL/SC (since you can't have a failure
unless someone actually manages to update the word in question).

[supe...@casperkitty.com]

On Monday, April 16, 2018 at 5:28:24 PM UTC-5, robert...@yahoo.com wrote:
> These are only for atomics, and livelock can't occur for single word
> updates for properly implemented LL/SC (since you can't have a failure
> unless someone actually manages to update the word in question).

Ideally a conditional store would never fail for any reason other than a
successful store by some other thread, but I don't think LL/CS-based
algorithms are supposed to rely upon that. It's considerably easier to
design hardware that pessimistically invalidates linked loads in cases
where an outside process might disturb the associated storage, than to
design one that will only invalidate if the storage is in fact disturbed.

[Tim Rentsch]

james...@verizon.net writes:

> [...] The only thing that

> the C standard actually says about what lock-free means (as opposed to
> what is says about how to determine if an object is lock-free) is in
> connection with signal handlers:
> "When the processing of the abstract machine is interrupted by receipt
> of a signal, the values of objects that are neither lock-free atomic
> objects nor of type volatile sig_atomic_t are unspecified, as is the
> state of the floating-point environment. The value of any object
> modified by the handler that is neither a lock-free atomic object nor of
> type volatile sig_atomic_t becomes indeterminate when the handler exits,
> as does the state of the floating-point environment if it is modified by
> the handler and not restored to its original state."
>
> If you're inferring anything about what lock-free means in a C context,
> other than what is implied by that paragraph, you're going outside the
> domain of the C standard.

Does this mean you're sure that the term lock-free is not defined
or otherwise mentioned in any of the normative references?

[Steven Petruzzellis]

Jasen Betts owns James Kuyper in every way possible. That's what James Kuyper does when he gets cornered. He of course creates a sock, starts a cross posted thread so he can claim here made a mistake. Hey it was my left hand... and then James Kuyper talks to his own post with his right hand.

James Kuyper insists that he uses Linux, while actually he never works with it on bare metal and actually pushed it.

Oh goodness, that is just tons of blarney. It was James Kuyper who got caught using untold numbers of nyms repeatedly, and these are 'people' who come clearly out of the blue straight into threads where he was being ripped apart... nonstop for years.

Protected code is best done with code morphing. For all the gloating James Kuyper has done on this topic, the 'College Professor' doesn't get how to do this. It really takes a couple seconds to highlight a range and 'orient' it. Jasen Betts and James Kuyper had their oversights and their mistakes. One presented it cool and didn't do anything too horrendous that could not be proved with tricks.



--
Do not click this link!
https://www.youtube.com/watch?v=u4xD43Khhkw
https://prescottareapsychopaths.wordpress.com/paul-f-riddle-psychopath/
https://prescottareapsychopaths.wordpress.com/paul-f-riddle-psychopath/
Jonas Eklundh

[james...@verizon.net]

No, I'm not - I don't have any of the normative references that might contain such a definition. As I remember it, ISO charges a pretty penny for several of those references, more than I can justify paying.

[Chris M. Thomasson]

On 4/13/2018 6:13 AM, James R. Kuyper wrote:

> On 04/13/2018 01:12 AM, Chris M. Thomasson wrote:
>> here is my main question:
>>
>> https://forum.pellesc.de/index.php?topic=7311.0

[...]

I just read some unfortunate news from Pelles C. It does not seem like
it will be able to handle atomic structures unless they explicitly add
it in a future release. They seem to understand the importance of this,
especially when C++11 compilers can already handle it.

https://forum.pellesc.de/index.php?topic=7311.msg27765#msg27765

Content
________________________________
Chris sorry for the delay in answer.

It is very clear that atomic access to large memory areas nowadays can
be efficiently performed on the majority of available architectures.

The PellesC compiler seems to handle only a minor subset of them, only
basic data types and the void pointer. This kind of implementation
doesn't need to analyze the object, and its size, to define if it can be
implemented in a lock-free fashion.

Such approach keep things simple maybe as first implementation.
I can't say if in a future release there will be in-compiler support for
lock-free atomic structures, only Pelle can decide.
________________________________

Damn! WHY do C++11 compilers support all of the threading, atomic and
membars... While C11 basically has to wave around the shi% stick!

Damn it!!!!


Well... Humm. I think I can hack something together that just might
work. On 32-bit, we can possibly use some gnarly non-portable casts to
stick two 32-bit pointers into a 64-bit unsigned integer. Or, perhaps I
can just use my own dwcas function that I gave them using CMPXCHG8B.

Need a little more time to tinker.

Btw, reading all of the comments in this thread. It is nice to be able
to talk about such things in C. Too bad it seems that there is only
_ONE_ compiler that is even trying to implement C11 threads, atomics and
membars.

Humm... Damn ;^o

[supe...@casperkitty.com]

On Wednesday, April 18, 2018 at 2:58:04 PM UTC-5, Chris M. Thomasson wrote:
> Btw, reading all of the comments in this thread. It is nice to be able
> to talk about such things in C. Too bad it seems that there is only
> _ONE_ compiler that is even trying to implement C11 threads, atomics and
> membars.

One of the major differences between C and C++ is that C functions are
often expected to call, and be callable from, arbitrary contexts
within other programs the C compiler knows nothing about. By contrast,
except when in an 'extern "C"' context, C++ functions are generally only
expected to be callable from within other C++ functions processed at the
same time by the same implementation. This makes it possible for C++ to
offer many features that C cannot, but at the expense of limiting the
contexts in which the compiled code can be used.

While it's useful to have a standard means via which implementations
targeting platforms with various atomic primitives can expose those
primitives to the programmer, there's far less value in trying to add
features which can only be emulated in ways that won't coordinate with
anything else in the system.

[Richard Damon]

I have NEVER heard of the assumption that a C++ function is only
callable from a file compiled at the same time as it was. There are
plenty of C++ based libraries.

Yes, to have C++ libraries you need a C++ calling convention ABI, but
most platforms have it.

At the very beginning, before such ABIs were standardized, you may have
had issues calling functions provided by a different implementation, but
you get exactly the same issue with C code, that if the implementations
do not conform to compatible C ABIs.

[Steven Petruzzellis]

Desk Rabbit created at least 20 virtual systems in the last year or so. Let us all have a moment of silence as we honor his accomplishments!

Advertising is a wonderful thing and consumer stupidity is even better. Dropping support for Mac Classic is common sense. Both Desk Rabbit and Oppenheimer had their snafus and their awkward moments. But one played it well and didn't do anything too publicly that could not be presented as stage magic.



-
Do not click this link!!!
https://youtu.be/lF8yk7ul4Mw
https://prescottareapsychopaths.wordpress.com/mark-bilk-psychopath/
http://www.5z8.info/lemon-party-redux_v1o7pm_nakedgrandmas.jpg
Jonas Eklundh Communication AB

[supe...@casperkitty.com]

On Wednesday, April 18, 2018 at 8:21:05 PM UTC-5, Richard Damon wrote:
> On 4/18/18 5:13 PM, supe...@casperkitty.com wrote:
> > One of the major differences between C and C++ is that C functions are
> > often expected to call, and be callable from, arbitrary contexts
> > within other programs the C compiler knows nothing about. By contrast,
> > except when in an 'extern "C"' context, C++ functions are generally only
> > expected to be callable from within other C++ functions processed at the
> > same time by the same implementation. This makes it possible for C++ to
> > offer many features that C cannot, but at the expense of limiting the
> > contexts in which the compiled code can be used.
> >
> > While it's useful to have a standard means via which implementations
> > targeting platforms with various atomic primitives can expose those
> > primitives to the programmer, there's far less value in trying to add
> > features which can only be emulated in ways that won't coordinate with
> > anything else in the system.
> >
>
> I have NEVER heard of the assumption that a C++ function is only
> callable from a file compiled at the same time as it was. There are
> plenty of C++ based libraries.

Such libraries typically require that imported and exported functions
be marked with an 'extern "C"' directive, do they not? And aren't many
C++ features and concepts limited to code that is not thus marked?

[james...@verizon.net]

On Thursday, April 19, 2018 at 5:19:12 PM UTC-4, supe...@casperkitty.com wrote:
> On Wednesday, April 18, 2018 at 8:21:05 PM UTC-5, Richard Damon wrote:

...

> > I have NEVER heard of the assumption that a C++ function is only
> > callable from a file compiled at the same time as it was. There are
> > plenty of C++ based libraries.
>
> Such libraries typically require that imported and exported functions
> be marked with an 'extern "C"' directive, do they not?

No, it's perfectly feasible to have libraries with functions that have
C++ language linkage.

> ... And aren't many

> C++ features and concepts limited to code that is not thus marked?

No. Language linkage affects only two things. One of those is function
types - the language linkage basically determines the calling convention
used to call the function and to obtain the value returned by that
function. The other is the relationship between the name used inside C++
code for functions and objects with external linkage, and the name given
to the linker when linking the entire program together. For example, with
C language linkage, the two names are generally very closely related -
the linker might see an "_" added at either the beginning or end of the
name. However, with C++ language linkage, the linker generally sees a
mangled name that uniquely identifies, among other things, the types of
the arguments of the function.

By clever use of typedefs, you can mix and match these things, creating,
for instance, a function whose name has "C" language linkage, and whose
type has "Pascal" language linkage.
This implies that function types with linkage for a particular language
cannot have an interface that uses C++ features with no comparable
feature in the specified language, so some limitations do apply.
Arguments and the return value cannot have types with no equivalent in
the specified language. Much of this implementation-defined, so in
principle a compiler could translate a function type with extern "C"
linkage that uses a C++ reference as if it actually used a pointer,
instead. However, inside the body of such a function, you can make use
of any feature of C++ you want (well, not quite - code which throws an
exception without catching it can be a problem for a function whose
type doesn't have C++ language linkage - but that's because throwing an
uncaught exception makes the exception effectively part of your calling
convention).

[Chris M. Thomasson]

On 4/16/2018 9:32 AM, supe...@casperkitty.com wrote:
> On Monday, April 16, 2018 at 11:19:24 AM UTC-5, robert...@yahoo.com wrote:
>> That's not what lock free means. If the operation is tagged as lock
>> free it means it'll be performed without using a mutex or similar
>> synchronization device.
>
> Is the definition of "lock-free" given on Wikipedia's "Non-blocking
> algorithms" page erroneous?

Traditional description of lock-free means that forward progress is
always occurring on any failure. For instance, if a CAS loop fails, it
means another thread made forward progress.

LL/SC can be different. For instance, if something else altered the
reservation granularity, well, that can cause a failure in SC where NO
forward progress has occurred.

> I could easily believe that the definition given there is not what the
> authors of the Standard *intended* the macro to indicate, but when I looked
> in the Standard for any definition of "lock free" I didn't find one.
>
> On some platforms, two threads running a minimal-length LL/CS loops may
> live-lock, but a more complicated (and slower) implementation may be able
> to guarantee forward progress in all cases.

Afaict, lock-free in the standard has to deal with the optimistic
implementation of atomic RMW operations. LL/SC is a perfect example. If,
say a simple atomic exchange operation has to be performed with a loop,
well, it can theoretically live lock. The programmer and underlying
architecture can do some special things to prevent this, but iirc that
behavior is out of the standards scope. This would be almost lock-free,
as per the lock-free C11 macros.

However, on systems that have pessimistic atomic RMW's like the x86,
well this can be considered wait-free because there is no loop.

Think of the weak and strong versions of CAS in C++ and C 11. The weak
was put in there to accommodate CAS being implemented with LL/SC. If you
use strong CAS on an optimistic system, then there will be a damn loop
in each individual CAS operation! However, strong CAS on pessimistic
systems like x86 or IBM CS instruction, well, there is no extra looping
overhead.

> In most use cases, the simpler
> implementation would be superior in every regard, since outside circumstances
> would never allow two threads to remain live-locked for very long. On the
> other hand, some use cases would require that implementations put in the
> extra effort to genuinely satisfy the definition "lock-free" given on
> Wikipedia.

Iirc, live lock is not outright prohibited by the standard. Hummm. I do
think I remember reading that atomic operations should try to complete
in a reasonable amount of time.

[Steven Petruzzellis]

Why does Jessica Lane focus on Takuya Saitoh's self-esteem issues so much? I believe we have two different notions for a good reason. You likely think Mint handles the desktop well. Nope. Not compared to anything else, really. Now that Takuya Saitoh understood how effective Jessica Lane is at playing 'injured party' he understands this isn't quite as insane as it seemed.

Give it up, man... even you have kill filtered that doofus. Given what he is no one should blame me for seeking to be rid of his nonsensical form of nonsense. Takuya Saitoh created at least one major circus in the last year or so. Without Linux that would not be possible.

You're like an elephant in the grass. We all see you hiding there and just laugh at you. And you're so stupid you keep rejecting it.

I'm not going to play like Takuya Saitoh did not aid me with Mac and I appreciate it. Jessica Lane has Takuya Saitoh as an example and could learn to at least pretend he grew a brain from now on... as always he stumbled when he first talked.

--
"You'll notice how quickly he loses interest when everything is about him. He clearly wants the attention"
Steven Petruzzellis, making the dumbest comment ever uttered.

[supe...@casperkitty.com]

Whether it is allowed or prohibited would depend upon whether "lock-free"
means the same thing in the Standard as it means elsewhere. Given that
the Standard doesn't really define the term in ways that would be relevant
to most of the circumstances where the types would be used, I don't see
any reason why quality implementations should not be expected to uphold
the normal meanings of words.

Even there, though, what's really needed in many cases is a guarantee which
is simultaneously looser and tighter than lock-free:

1. *Most* programs don't need to be proof against live-lock even in
situations which would be deliberately designed to cause it, so long
as there is probably zero that they wouldn't be shaken loose within a
reasonable length of time.

2. Many programs for free-standing implementations require that atomic
operations be atomic with regard to code produced by something other
than the C implementation. If an implementation uses an algorithm--
even a lock free one--which would require that every atomic object
have an owner which is known to all of them, any objects that the
implementation would have to own would be unusable with any outside
code that isn't expecting such ownership.

[Steven Petruzzellis]

Where did you learn to program? Both Jonathan Rhodes and Paul 'The Fool' Riddle had their omissions and their discomfort. But one played it as supernatural and didn't do anything too publicly that could not be tricking people until it was too late. The one thing Paul 'The Fool' Riddle learned fully is to attempt to shame Jonathan Rhodes into false confession and if that fails to work, shout him down or dishonesty change the assertion. It was Paul 'The Fool' Riddle who flooded Jonathan Rhodes's site thousands of times and denied it. The guy is as well liked as pork pie in a mosque -- and with good reason. After Jonathan Rhodes's update I no longer have a working system. Thanks Fedora! BTW, I've already proved that his use of "herd" to describe true advocates is argumentum ad hominem, since he's likening them to mindless sheep.

--
Do not click this link!

https://www.youtube.com/watch?v=AglvCo3dJ38&feature=youtu.be
http://tmp.gallopinginsanity.com/BilkHelp.html
Jonas Eklundh Communication

[Chris M. Thomasson]

I don't think C or C++ 11 can tell programs that they cannot livelock!
If they did this then the standard would be intruding an actual
synchronization implementations. This would be bad.

[supe...@casperkitty.com]

On Friday, May 4, 2018 at 4:05:05 PM UTC-5, Chris M. Thomasson wrote:
> I don't think C or C++ 11 can tell programs that they cannot livelock!
> If they did this then the standard would be intruding an actual
> synchronization implementations. This would be bad.

The question isn't whether programs can live-lock, but whether an
implementation can claim that a primitive is lock-free if there are
any conditions (possibly contrived) where where *the primitive itself*
would live-lock.

[Chris M. Thomasson]

Afaict, this is where "sometimes" lock-free comes into play, for
instance a value of 1 for the ATOMIC_*_LOCK_FREE macros:

http://en.cppreference.com/w/c/atomic/ATOMIC_LOCK_FREE_consts

;^)

[Steve Carroll]

His desire is to see DFS annoyed by idiotic lying. And hey, that could or could not... you know what I mean. It was Sandman Script Troller who flooded DFS's site dozens of times and denied it. By the way, spending effort perhaps learning is never a waste. Believing you know more than everyone else and taking it on yourself to persuade others that it's true? That is a waste.



--
Live on Kickstarter!
https://youtu.be/VxLiH-x0aeY
https://youtu.be/BUjnZhKk1Bg
Jonas Eklundh Communication

[supe...@casperkitty.com]

Having a never/sometimes/always indication at compile time could be
useful if it were combined with a run-time test. For example, if
there were a variation of atomic increment that could time out
without successfully writing the destination, then on systems where
such an operation might time out, it may be useful to generate code
that would perform a "try increment without blockiong" and then
handle the possible failure, but on systems where the attempt would
always succeed, the failure-handling code would be a waste.

Since atomic operations don't have "try without blocking" forms, I'm
not sure what a program should do with the fact that an operation
might be lock free.

[Chris M. Thomasson]

On 5/6/2018 4:07 PM, supe...@casperkitty.com wrote:
> On Sunday, May 6, 2018 at 12:56:32 AM UTC-5, Chris M. Thomasson wrote:
>> On 5/4/2018 2:20 PM, supe...@casperkitty.com wrote:
>>> The question isn't whether programs can live-lock, but whether an
>>> implementation can claim that a primitive is lock-free if there are
>>> any conditions (possibly contrived) where where *the primitive itself*
>>> would live-lock.
>>
>> Afaict, this is where "sometimes" lock-free comes into play, for
>> instance a value of 1 for the ATOMIC_*_LOCK_FREE macros:
>>
>> http://en.cppreference.com/w/c/atomic/ATOMIC_LOCK_FREE_consts
>
> Having a never/sometimes/always indication at compile time could be
> useful if it were combined with a run-time test. For example, if
> there were a variation of atomic increment that could time out
> without successfully writing the destination, then on systems where
> such an operation might time out, it may be useful to generate code
> that would perform a "try increment without blockiong" and then
> handle the possible failure, but on systems where the attempt would
> always succeed, the failure-handling code would be a waste.

Imvho, the standard should not intrude this far into an implementations
atomics setup. An system should be allowed to live lock all it wants.
The standard should not give a shi%. Heck, even obstruction free is
allowed as well. ;

> Since atomic operations don't have "try without blocking" forms, I'm
> not sure what a program should do with the fact that an operation
> might be lock free.

Why in the world would you think about adding a try without blocking to
an atomic primitive? Btw, the is a runtime check for the level of lock
free'ness:

http://en.cppreference.com/w/cpp/atomic/atomic_is_lock_free

The standard should allow for all sorts of different implementations of
atomic operations. Imvho, the std has no right to tell me that my stuff
cannot live lock. Heck, I can define:

ATOMIC_BOOL_LOCK_FREE as 1 if I want to!

sometimes lock-free... ;^)

[Steve Carroll]

A flaming bush that never burns, magnified by the reciprocal of a mere moment in a cosmological time scale, demonstrating the vast nothingness of Jesus's so-called thought process.

It's a long, long conflict, and Jesus is simultaneously an expert bullshiter of trolling remarks, while posting with nyms that speak just like him. Jesus only thinks about Michael P., Michael P., Michael P.! What were you betting on?

A shadow of false cognition, projected quickly, at the wrong time.



--
Eight things to never feed your cat
http://www.5z8.info/stalin-will-rise-again_j3h5uj_nakedgrandmas.jpg
http://www.5z8.info/killallimmigrants_t8w8io_asian-brides
Jonas Eklundh Communication

[supe...@casperkitty.com]

On Sunday, May 13, 2018 at 11:08:55 PM UTC-5, Chris M. Thomasson wrote:
> Imvho, the standard should not intrude this far into an implementations
> atomics setup. An system should be allowed to live lock all it wants.
> The standard should not give a shi%. Heck, even obstruction free is
> allowed as well. ;

The fact that an implementation will arbitrarily and unpredictably hang
and cease all operations would not render it non-conforming if it
refrained from such behavior when given the One Program. A quality
implementation, of course, should avoid behaving in such fashion as such
behavior would render an implementation unsuitable for many purposes,
but such behavior wouldn't make it non-conforming.

An implementation which does not protect against live-lock would be suitable
for use with code that includes manual guards against live-lock, or for use
in environments that would make sustained live-lock impossible. That does
not mean it's suitable for all purposes, however.

> > Since atomic operations don't have "try without blocking" forms, I'm
> > not sure what a program should do with the fact that an operation
> > might be lock free.
>
> Why in the world would you think about adding a try without blocking to
> an atomic primitive? Btw, the is a runtime check for the level of lock
> free'ness:
>
> http://en.cppreference.com/w/cpp/atomic/atomic_is_lock_free
>
> The standard should allow for all sorts of different implementations of
> atomic operations. Imvho, the std has no right to tell me that my stuff
> cannot live lock. Heck, I can define:
>
> ATOMIC_BOOL_LOCK_FREE as 1 if I want to!
>
> sometimes lock-free... ;^)

If a programmer knows that live-lock isn't a danger, then an implementation
with no protection against it may be more efficient than one that includes
such protection.

On the other hand, if a programmer knows that code will be used in an
environment which would have an unusually high risk of live lock, then
it may be helpful to have a means by which the programmer can indicate
that any implementation must either protect against live lock or else
reject the program as unsuitable for use with it.

IMHO, instead of focusing on mandating a set of features that all
implementations must support, the Standard should focus on a set of
features that programmers could demand, and which implementations could
support or not at their leisure, with the sole requirement that an
implementation that cannot support the semantics required by a program
must Fail in some implementation-defined fashion.

[Steve Carroll]

Just give it up already. You're again trying to push your ego when you have no skill. You're the village idiot and your many hare-brained videos show this. This is something you know nothing about. James Kuyper calls it "attacking" him, even though he proceeds to cause that selfsame criterium. And you do, of course realize that it isn't impossible for James Kuyper to be doing this, or paying one of his programmer "friends" to do it. So what is James Kuyper's system for the flooding deluge? AppleScript? That is the only database he knows, isn't it? He must be using it to write these goofy "spam" idiotic threads. My hypothesis, James Kuyper took a FireFox extension that he pirated and try to sell online... he's feeding it MuahMan's posts, grabbing random paragraphs, then editing those using automated reinforcement learning and then he annoyingly posts them because his lack of work enables him to do that round-the-clock.

Most people in this forum do programming either as a necessity or as a career, so I am skeptical anyone here think of writing macros to be "witch craft".



--
Puppy Videos
http://www.5z8.info/yourdick_v1o3ww_manhunter
Jonas Eklundh Communication