Subj : Re: Adding thread support for C... To : comp.programming.threads From : David Hopwood Date : Sat Jul 23 2005 09:06 pm Markus Elfring wrote: >>The code that you are trying to write implements concurrency primitives, >>which you should not expect to have a portable implementation in C. It makes >>little sense to try to implement these things in C, since C neither has a >>well-defined concurrent semantics of its own, nor does it expose the >>semantics of the underlying machine in a usable way. That's why you can >>only work around various problems by inhibiting optimizations: it is impossible >>to write correct code in C that meets the requirements, only code that happens >>to work for particular implementations of C. > > Do you need to stop an assembler optimiser to break multithreaded code? For most purposes, an assembler program can be treated as deterministically specifying a machine code program, which can be directly submitted to the hardware. The machine language accepted by the hardware does have a well- defined concurrency semantics -- or at least that is the intention, modulo any ambiguities in processor architecture documents. An assembler optimizer, unlike any optimizer that is part of a C compiler, is normally considered to be a separate process that takes an assembler program as input and spits out another assembler program as output. If a particular assembler optimizer transforms the code in ways that you don't want, then just don't use it. For C, there is no such thing as directly executing the C code on a processor, and so there is no well-defined option to "not do any optimization". Assuming a compiled C implementation, any optimization will be done as part of translating the C to machine code, which cannot be the identity transform. > How do you avoid that a linker will do any damage to the desired execution paths? That's a good point: machine-level programs are usually presented to an OS not as raw machine code, but in an executable format that is further transformed by a dynamic linker. In practice, you can either: - assume that the linker doesn't do any damage, or - generate machine code at runtime, which is not visible to the linker. If the program is running on a virtual machine, hypervisor, emulator etc., you also have to assume that it will not break the code (but in that case, there is still a concurrent machine model that the VM/hypervisor/emulator is trying to conform to). -- David Hopwood .