volatile?

Rein Halbersma · Post by **Rein Halbersma** » Sat Mar 29, 2014 9:14 pm

bob wrote:
Rein Halbersma wrote:
bob wrote:
syzygy wrote:
bob wrote:
Pretty funny discussion however, since the KERNEL uses volatile for its own spin locks among other things..
Your insight in these matters is just amazing.
Just factual. Want me to show you the volatile ints in the kernel source for spin locks?
Yes, please show us:

https://github.com/torvalds/linux/blob/ ... spinlock.h
https://github.com/torvalds/linux/blob/ ... spinlock.c
See my reply to Ronald right below this post. I found a thousand just going a few levels deep in the directory structure for 3.13.6, the current fedora 20 kernel.

Care to try again?

Or at least LOOK again?

I did LOOK at the latest Linux Kernel source code that implements spinlocks. Not a volatile in sight.

It looks like the lock stuff was completely rewritten, eliminating the spin locks that burn cycles, adding a queue that everyone lines up in to gain access. Cute idea.

Yes, and this was not done silently, but after a huge debate on lkml all the way back in 2006: http://lkml.iu.edu//hypermail/linux/ker ... /1449.html You should read Linus's comments on the use of volatile, you might be surprised, and who knows, you'll learn something.

But wait, there's more: it even got summarized in an abridged version for challenged readers on LWN.net back in 2007: http://lwn.net/Articles/233482/

STILL plenty of volatiles around.

Oh yes, your side argument of looking at all other non-spinlock related code. Well, true, there is plenty of volatile, even in the Linux Kernel. In fact, in 2006 there were over 10K occurances of volatile in the entire source tree. Most of them in drivers, and many of them are still there. But NOT in the spinlock code itself anymore.

The lock used in Crafty came from older kernel sources. Still works flawlessly.

Erm, you might want to read the links I posted above.

syzygy · Post by **syzygy** » Sat Mar 29, 2014 9:51 pm

The volatile in spinlock_types_up.h (uni-processor...) is also not really there:

Code: Select all

#ifdef CONFIG_DEBUG_SPINLOCK

typedef struct &#123;
        volatile unsigned int slock;
&#125; arch_spinlock_t;

#define __ARCH_SPIN_LOCK_UNLOCKED &#123; 1 &#125;

#else

typedef struct &#123; &#125; arch_spinlock_t;

#define __ARCH_SPIN_LOCK_UNLOCKED &#123; &#125;

#endif

It's only there for debugging reasons (that I won't pretend to understand).

wgarvin · Post by **wgarvin** » Sun Mar 30, 2014 12:30 am

syzygy wrote:The volatile in spinlock_types_up.h (uni-processor...) is also not really there:
Code: Select all
&#40;code&#41;
It's only there for debugging reasons (that I won't pretend to understand).

Most likely, its so that when debugging crashes and you see that code in the debugger, the proper value of the variable will always be found in memory. If it wasn't volatile, then when looking at assembly code that accessed it you would have to figure out if it was currently live in a register or something. It would be nice if debuggers just always got this right, but for optimized code most of them still don't.

syzygy · Post by **syzygy** » Sun Mar 30, 2014 12:52 am

wgarvin wrote:
syzygy wrote:The volatile in spinlock_types_up.h (uni-processor...) is also not really there:
Code: Select all
&#40;code&#41;
It's only there for debugging reasons (that I won't pretend to understand).
Most likely, its so that when debugging crashes and you see that code in the debugger, the proper value of the variable will always be found in memory. If it wasn't volatile, then when looking at assembly code that accessed it you would have to figure out if it was currently live in a register or something. It would be nice if debuggers just always got this right, but for optimized code most of them still don't.

But in this case there is no variable at all in the non-debug case.

Maybe it is somehow easier to debug spinlock related matters on a uniprocessor kernel...

wgarvin · Post by **wgarvin** » Sun Mar 30, 2014 1:03 am

syzygy wrote:
wgarvin wrote:
syzygy wrote:The volatile in spinlock_types_up.h (uni-processor...) is also not really there:
Code: Select all
&#40;code&#41;
It's only there for debugging reasons (that I won't pretend to understand).
Most likely, its so that when debugging crashes and you see that code in the debugger, the proper value of the variable will always be found in memory. If it wasn't volatile, then when looking at assembly code that accessed it you would have to figure out if it was currently live in a register or something. It would be nice if debuggers just always got this right, but for optimized code most of them still don't.
But in this case there is no variable at all in the non-debug case.

Maybe it is somehow easier to debug spinlock related matters on a uniprocessor kernel...

Oops. yeah. I guess to know what its for, we'd have to search for that CONFIG_DEBUG_SPINLOCK macro elsewhere and see what they are storing in there. But anyway its not part of the lock itself. It might just be extra info to aid humans who are viewing it in a debugger, or perhaps it is part of some feature that tries to detect misuses of the lock, or situations where its been waiting for an abnormally long time, or something like that.

bob · Post by **bob** » Mon Mar 31, 2014 4:42 am

syzygy wrote:
bob wrote:
syzygy wrote:
bob wrote:
syzygy wrote:Those locks were not amateuristically written by Mr Hyatt, but include the necessary compiler and hardware memory barriers.
Your ignorance is showing. My lock was NOT "amateurishly written by me.
I referred to those you fabricated by copying and pasting from the pthreads source.
Let me get this straight. You REALLY want to claim that the ONLY way one can use the pthread library is to use it in its pre-compiled form?
I am saying that POSIX does not guarantee that if you randomly copy and paste stuff into your program you end up with something that works.

Can you cite a source? (hint: such a source does NOT exist, because that is NOT a requirement for using the pthreads library. In fact, if it were a requirement, it would break way too much because library behavior is defined, specifically, to behave IDENTICALLY with behavior produced when the library source code AND the application are compiled together. That is the very DEFINITION of a library, it eliminates the NEED to compile the library source each time it is used. It does NOT preclude doing so.
OK, why don't you file a bug report to the pthreads maintainers so that they can have as big a laugh at you as we are having.

From the start of this thread, posted by Alvaro:
http://pubs.opengroup.org/onlinepubs/96 ... #tag_04_11
The following functions synchronize memory with respect to other threads:
...
pthread_mutex_lock()
...
If your POSIX system doesn't do this, it is buggy. You believe you found a bug, so report it. Woohoo.

I did not "randomly copy and paste". I will repeat. At one point the pthreads library was NOT in glibc. I am not sure it is in glibc for all implementations for that matter, as on some systems I need -lpthread and on others I do not. I simply included that complete source into Crafty and compiled.

There is absolutely NOTHING in the posix standard for libraries that says "you can link against the libraries and get correct results, but if you compile the code in with your executable, you will not." That would be a MAJOR warning somewhere. If it existed.

syzygy · Post by **syzygy** » Mon Mar 31, 2014 8:24 am

bob wrote:
syzygy wrote:
bob wrote:
syzygy wrote:
bob wrote:
syzygy wrote:Those locks were not amateuristically written by Mr Hyatt, but include the necessary compiler and hardware memory barriers.
Your ignorance is showing. My lock was NOT "amateurishly written by me.
I referred to those you fabricated by copying and pasting from the pthreads source.
Let me get this straight. You REALLY want to claim that the ONLY way one can use the pthread library is to use it in its pre-compiled form?
I am saying that POSIX does not guarantee that if you randomly copy and paste stuff into your program you end up with something that works.

Can you cite a source? (hint: such a source does NOT exist, because that is NOT a requirement for using the pthreads library. In fact, if it were a requirement, it would break way too much because library behavior is defined, specifically, to behave IDENTICALLY with behavior produced when the library source code AND the application are compiled together. That is the very DEFINITION of a library, it eliminates the NEED to compile the library source each time it is used. It does NOT preclude doing so.
OK, why don't you file a bug report to the pthreads maintainers so that they can have as big a laugh at you as we are having.

From the start of this thread, posted by Alvaro:
http://pubs.opengroup.org/onlinepubs/96 ... #tag_04_11
The following functions synchronize memory with respect to other threads:
...
pthread_mutex_lock()
...
If your POSIX system doesn't do this, it is buggy. You believe you found a bug, so report it. Woohoo.
I did not "randomly copy and paste". I will repeat. At one point the pthreads library was NOT in glibc. I am not sure it is in glibc for all implementations for that matter, as on some systems I need -lpthread and on others I do not. I simply included that complete source into Crafty and compiled.

There is absolutely NOTHING in the posix standard for libraries that says "you can link against the libraries and get correct results, but if you compile the code in with your executable, you will not." That would be a MAJOR warning somewhere. If it existed.

I repeat: file a bug report. Let those maintainers have a good laugh as well. Thank you.

volatile?

Re: volatile?

Re: volatile?

Re: volatile?

Re: volatile?

Re: volatile?

Re: volatile?

Re: volatile?