Re: pthreads and standard C library calls and maybe magic Xcode switches
Re: pthreads and standard C library calls and maybe magic Xcode switches
- Subject: Re: pthreads and standard C library calls and maybe magic Xcode switches
- From: Alastair Houghton <email@hidden>
- Date: Wed, 22 Aug 2007 17:45:30 +0100
On 22 Aug 2007, at 15:55, Cem Karan wrote:
Well, my understanding of it is that volatile signals that the
compiler cannot optimize away a memory access,
[snip]
by marking the variable as volatile, you are telling the compiler
that it MUST push everything out to RAM. Am I right?
Not exactly. You're telling the compiler that it must issue a memory
write instruction (or a memory read instruction) for every read/write
you do of the variable, and also that it shouldn't re-order these
reads and writes for any reason. You're also telling it that it
shouldn't cache the value in a register.
The processor, however, may choose not to write the data to RAM until
later on, and may even (on processors with weak memory ordering)
choose to re-order reads and writes unless you tell it not to.
That said, all pthread locking functions are guaranteed to act as a
memory barrier, so if you use those you do not have to add any
additional barriers yourself.
OK, thanks, that was what I was wondering about. My concern is
that as Apple introduces new hardware in the future, it may choose
to use somewhat more exotic processors that won't maintain their
cache coherency. In that case, my code would break, and I really,
really, REALLY hate tracking down thread problems, especially in
old code.
You can write "valid" pthreads programs, even with locking, that
won't work right. Hans Boehm wrote a paper about this problem:
<http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html>
It's worth reading. Fortunately most modern compilers don't do the
transformations that make locking code work the wrong way, but---
unless you write "volatile"---they're perfectly at liberty to do so
according to the C standard.
On Wed, 22 Aug 2007 07:37:05 -0400, Cem Karan wrote:
Are you saying that the locking constructs will ensure that the cache
is always flushed back to main memory?
No. But they will enforce strong memory ordering at those
boundaries. That is, when you take a lock, it is guaranteed that all
writes prior to that lock (will *seem* to have) completed from the
perspective of other processors in the system.
(If you're writing very low-level code, e.g. for device drivers, you
may find that those writes *haven't* actually completed from the
point of view of your device, in which case you may need to do a bit
more... but that's another story.)
On Wed, 22 Aug 2007 14:18:19 +0200, Olivier Tristan wrote:
If you're using your memory for real time data feed from outside,
lock
can hurt performances a lot, then take a look at some LockFree
RingBuffer impl.
I know of a few lock-free algorithms, but I'm always worried that
I'll get the implementation wrong in some extremely subtle manner;
do you know of any good books that explain these algorithms well?
I can search, but I don't know if I'm getting good books or bad.
I'd also be interested to hear if anyone knows of any books on that
topic. I've written and used lock-free code myself; doing it right
is quite tricky (especially if you're inventing the algorithms
yourself), and I remember seeing and reading about several instances
where researchers had actually got their algorithms wrong in some
subtle manner (typically, missing out memory barriers). Writing lock-
free code with barriers *everywhere* is one way to make the problem
easier, though performance will suffer somewhat as a result.
Incidentally, if you do try to write lock-free code, make sure you
test on PowerPC or SPARC or some other architecture with weak memory
ordering. Intel Architecture processors have (for the most part)
strong memory ordering, and will therefore mask bugs that would occur
on other architectures.
A nice, general solution, that is quite easy to use is Software
Transactional Memory. There are some public domain implementations,
and I've been toying with one for Objective-C, though I can't publish
it at present because of the Leopard NDA (it knows how to interact
with GC on Leopard...).
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden