Date: Mon, 17 Jan 2000 09:34:23 -0500 From: "Mikhail Evstiounin" <evstiounin@adelphia.net> To: <freebsd-questions@FreeBSD.ORG> Subject: Re: Volatile variables Message-ID: <00f501bf60f7$f37ff0a0$ed353018@evstiouninadelphia.net.pit.adelphia.net>
next in thread | raw e-mail | index | archive | help
-----Original Message----- From: Oliver Fromme <olli@dorifer.heim3.tu-clausthal.de> To: freebsd-questions@FreeBSD.ORG <freebsd-questions@FreeBSD.ORG> Date: Monday, January 17, 2000 1:18 AM Subject: Re: Volatile variables > >No. Except if your processor is broken. :-) Oliver, what about timer registers or serial interface registers? what about mapped video memory or shared memory in multi CPU system? > >There is no concurrency. Even if you have two processors, >the signal handler will not run in parallel to the "main" >part of the program. > I agree completely, I was trying to stress a difference between sighandler and threads and unix processes. > >>No, it is not. In particular, the compiler is unable to take > >>it into consideration during register optimization. > > > > Again, you missed my point - you as a programmer, not as > > a compiler. You can mask signals. > >Yes, but that's completely unrelated to "volatile". >You have to mask signals to ensure proper synchronisation and >avoid race-conditions. You're right about this. This has >nothing to do with "volatile" and register optimizations. > >But setting singal masks does not prevent those register >optimizations. You _must_ use "volatile" for this. > In a way, how you proposed - yes, but it's not enough. > >>In theory, if the processor hardware has enough registers, > >>_all_ variables of the whole program could be held in registers > >>during the _whole_ lifetime of the process. There would be > >>never a variable stored in memory. This is perfectly legal, > >>and a programmer whould have no chance to access them from > >>within a signal handler. > > > > You are wrong here again. > >Then please explain why you think so. >What I said is correct. > You were wrong about registers, it's possible to write compiler/loader to support it. GNU C doesn't support it, but, in my mind we were talking about vilotile in general - without relationship to a particular compiler. If you were talking about gcc and FreeBSD only, then I should say sorry, I misunderstood you. > > I was a member of team that wrote compiler > > allocating global variables in registers. And it worked. > >Was it a C compiler? In that case I hope it supported >"volatile" correctly, otherwise it would be in violation >of the standard. > Yeap, and C also. And we supported vilotile in a sense no synonyms, no copies. Probably, that the fact I used 'synonym' is bad one. It was (is?) a slang. Remember - synonyms two words with same meaning - you can have two copies of value with the same contents - as I understood, this is exactly you refered as a register optimization. But we did allocate some variables on registers - and this is a register optimization. We were fortunate enough to write the whole system and wrote very smart linker/loader which could understand register allocation and change command apropriately. > > except some special address scheme and speed there is no big difference > > between memory and registers from the point of view of a compiler. > >Except that register optimizations are forbidden when a >variable has been declared as "volatile". Oliver, this is my point - there could be other register optimizations and if your system smart enough it could be used - I just don't like to forbid all register optimization. Take a look at PDP-11 - here you can address registers as usual with register number aor you can address them by using special addresses in memory - it's very easy to provide register optimization compatible with vilotile. > > >>"BS book"? How about quoting from an authoritative reference? > > > > OK, Bjarne Stroustrap is not authorative, even it's a base for standard > > or created based on standard drafts? > >I think we're talking about C, not C++. I'm not familiar with >usage of "volatile" in C++ (and this was not the question). > > >> movl i,%eax > >> movl i,%edx > >> imull %edx,%eax > >> movl %eax,j > >> movl j,%eax > >> movl i,%edx > >> addl %edx,%eax > >> movl %eax,j > >> > >>As you can see, now the contents of i and j are always > >>consistent. This code works fine, even when an asynchronous > >>mechanism (signal handler, hardware, etc.) tries to access > >>them at some point. > >> > > > > For Chrises sake tell me what is going to happen if you got > > interrupted after first movl? > >If the signal handler changes the value of "i" at that point, >then the second usage of "i" will get a different value than >the first usage, which is the _correct_ behaviour. > Aga, this is exactly what I was talking about - two sequential reads of variable could give you different results - that's why using vilotile is not enough. That's why this is synchronization problem. Yes this is correct behavior, but it doesn't help to solve original problem. It's necessary part in way how it's prpoposed to solve, but it's not enough. >Without "volatile", the gcc code will always use the old value, >which is _not_ correct. Even worse, the behaviour depends on >the compiler's optimizer -- it _might_ use the old value, or it >might not. > > > eax and completely differend on edx. Vilotile does help > > you to avoid synonyms, but doesn't help you to solve your problem. > >Excuse me? It solves the problem. The code does exactly what >it's supposed to do. Correct if I am wrong, but original question was how to work with global file pointer from a sighandler. And I considered that this file pointer is a global resource and you have a problem in sighandler to be interrupted by amother sighandler and this another sighandler could use the same file pointer. Or you can get signal in main program while it's working with file pointer and get access to it from sighandler. > > > there is no warranty that j will always have value of > > square of i. > >Correct. There is no such warranty, no matter if "i" is >declared as "volatile" or not. > >If the signal handler changes the value of "i", the programmer >should know what he is doing. If he wants to calculate the >square of "i", he should use a different way (i.e. using signal >masks). or m = i; j = m*m; :-) create your own copy. > > > Vilotile tells to compiler (and to programmer) > > that j can have a very strange result. > >That's completely wrong. So, if programmer wites j = i * i; (s)he doesn't expect to get a square? I understand, that according to standard vilotile means it, but it's not intuitive. That's why I told that vilotile tells to compiler and to programmer - expect something strange. > > > Oliver, I don't want to tell anybody - don't use vilotile. > >Then you cannot use global variables within signal handlers >correctly. I'm under the impression that you misunderstand >the purpose of "volatile". > Nope, I believe, my understanding of vilotile is OK, but I am not attributing to it more than it deserves. I think you see this way of communicating with sighandler as the only way. I believe, there are many more. But it's not easy, you should work with async safe functions and write a special stuff to work with sharable resources and avoid deadlocks (and it's very easy to get them with sighandlers). All this stuff is pretty common if you are in concurrent programming (it doesn't make any difference if this is threads or processes - theory is still the same). But using vilotile plus sigblock/sisetmask is enough to get out without any troubles and without using a pretty complex theory. >Regards > Oliver > >-- >Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany >(Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) > >"In jedem Stück Kohle wartet ein Diamant auf seine Geburt" > (Terry Pratchett) > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-questions" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00f501bf60f7$f37ff0a0$ed353018>