Re: Threading - How its done?
Re: Threading - How its done?
- Subject: Re: Threading - How its done?
- From: Army Research Lab <email@hidden>
- Date: Wed, 07 May 2008 09:13:22 -0400
- Thread-topic: Threading - How its done?
Karl von Moller wrote on Wed, 7 May 2008 09:51:56 +1000:
> Thanks to all that posted.
>
>> To the original poster:
>>
>> How much experience do you have with threads? I'm a little confused
>> reading through your posts, I can't tell if you are familiar with
>> pthreads, and just need to figure out NSThreads, or if you have no
>> threading experience at all.
>
> As I said earlier on, I don't have ANY experience with threading at
> all - this was my first attempt to try and understand how to implement
> a threading scheme. The Apple documentation was my first port of call
> and at least the basics of it, I got from those articles. I found a
> great deal of reading material online however I think the noise of
> hearing the same comments "Threading is hard ..." etc made this all
> the more difficult. This mailing list has in one day at least, given
> me some clear guidance on my next approach which I really appreciate.
> At some point though, to take things out of the theoretical, you have
> to put things into practice. Granted my approach may have been very
> hit and miss but it certainly accelerated my learning!
In that case, I suggest getting used to pthreads with some simple C
programs first. This will reduce the number of things that can go wrong
to a fairly small minimum (you don't have to wonder if its you or
Cocoa). Many of the common C standard libraries are now required to be
thread-safe (at least, if you are using C99), so things like printf()
will work out of the box. A fairly good book to learn from is
Programming with POSIX Threads by David R. Butenhof.
(http://www.amazon.com/Programming-Threads-Addison-Wesley-Professional-Compu
ting/dp/0201633922/ref=pd_bbs_1/104-4945869-2700757?ie=UTF8&s=books&qid=1210
159650&sr=8-1)
Once you understand the basics of what threads are, then you can start
working on NSThreads (which, IIRC, wrap pthreads).
As for why threads are 'hard'; in reality, they aren't hard, as long as
you are absolutely fastidious in following the rules:
1) Don't access shared variables unless you've got possession of the
lock. If you must own several different locks at the same time, enforce
an ordering on how you grab the locks; that is, if each thread must own
locks A, B, and C in order to get any work done, then the threads must
lock the locks in that order each time. I'm sure you've read about
deadlock by now; the fastest way to cause it is to have one thread grab
locks A, B and then another one to grab them B, A. Somewhere along the
line, one thread will have A and be waiting for B, while the other has B
and is waiting for A. Enforcing an order prevents this.
2) Check your condition variables in a while loop, to make sure you
weren't woken up by accident.
3) I don't care how 'small' or 'atomic' the shared variable is, use a
lock.
4) Signals are bad in multi-threaded environments; accept that the
system may pass signals to you, but don't use signals yourself. BTW,
the pthreads API is a little confusing here, there is a function in
there called 'pthread_cond_signal()'. That one is safe to use, although
'pthread_cond_broadcast()' is better for beginners. The one that can be
dangerous is 'signal()' (see 'man 3 signal').
5) WHAT PART OF 'USE A LOCK' DIDN'T YOU GET???
Sorry, that last one is for all the code I've had to debug over the
years...
Here are some of the reasons that threads are 'hard'
1) Threads introduce non-deterministic behavior into your program; just
because it didn't crash this go around, doesn't mean it won't crash the
next time, or on someone else's machine. This non-determinism is VERY
hard to debug, because the mere act of loading the code up in a debugger
will cause the program's behavior to change, possibly masking what went
wrong.
2) Compilers are smart; they'll keep stuff in registers as long as
possible, including things that are shared between threads. Anything
that is shared, but in a register, won't be seen between threads, so code
that should be sharing stuff won't be. That is one reason why you MUST
use a lock around all shared variable access, and around any 'sensitive'
code (code that temporarily breaks invariants). Part of the code of the
lock includes something like OSMemoryBarrier() in
/usr/include/libkern/OSAtomic.h. A memory barrier forces anything that
is supposed to be in memory to be written all the way out to main memory
before any further processing happens; that ensures that shared
variables are updated properly.
3) 'Small' variables like chars or ints look like they should be written
atomically to main memory, but this isn't always the case; on some
systems, the only way to write out a single character is to read in 32
or 64 bits, mask off the portions of the variable you don't want to
change, write the character into the variable, and then write the whole
32 or 64 bit chunk back into memory. That means that without a lock,
even a char can cause problems.
4) Threads all share the same address space, but have different stacks.
The stack is the important problem here; it is possible to have a stack
that is so deep that one thread's stack overwrites another thread's
stack (look up 'stack smashing', which is similar). This might not seem
likely until you've run into anyone that attempts to put large arrays
onto the stack, or finds highly recursive functions to be a pleasure to
use. Valgrind (http://valgrind.org/) is particularly nice for finding
this, but it is Linux only for right now. There are other tricks to use
to solve this as well, but they are basically hacks (e.g. guard pages
and other canaries, etc.)
In general, I'd say threading isn't any more or less difficult than any
other programming; its just that if you're used to hacking something out
and then using the debugger to fix the problems, then it will be hard.
If you plan and design carefully, choosing what will be shared and what
will be private, then it won't be too bad.
>> to have a pool of worker threads that render the thumbnails/PDFviews
>> in the background. It would simply be a matter of having a
>> thread-safe priority queue (so if the user clicks on a thumbnail, it
>> gets jumped to the head of the queue), and let the threads grab
>> whatever happens to be the highest priority to work on, returning the
>> results to the main thread to display later. Alternatively, each
>> time you click on a thumbnail, it could spawn a thread, with the
>> thread returning the results to the main thread when it is done.
>
> This idea is exactly what I was trying to achieve - The idea of the
> thumbnail creation and the PDF loading happening in a separate thread.
> However to have a thread safe priority queue to organize the "Worker
> Threads" sounds like the missing link - And with that some safe way to
> cancel Threads that have been outdated by the user before that Thread
> had time to set the PDF View! I am assuming in a priority queue this
> function could exist?
A priority queue is simply a way of organizing chunks of data, much like
a regular queue, a tree, or another data structure. The thread safety
comes from protecting all accesses via locking; e.g., the queue's
appendData() function will internally lock a lock, do all changes that
are necessary, and then release the lock before returning from the call.
One of the simplest ways to do this is to write an ordinary queue (or
use something like stl::priority_queue<>) and then write a wrapper using
a decorator pattern that handles the locking. This lets you use return
statements anywhere you want in the ordinary queue, while the
thread-safe wrapper catches the return value, and does the necessary
unlocking. E.g. (all code written in my mail client, may have bugs):
#include <assert.h>
#include <pthread.h>
#include <stddef.h>
#include <stdint.h>
struct nonLockQueueContext
{
uint8_t *data;
size_t dataSize;
};
struct lockingQueueContext
{
struct nonLockQueueContext nonLockingContext;
pthread_mutex_t lock;
};
int nonLockingInsert( struct nonLockQueueContext *context,
void *data, size_t dataSize)
{
if (context == NULL)
return -1;
if (data == NULL)
return -2;
if (dataSize == 0)
return -3;
// Any other checks and return values you can think of
// Put the data in the queue
return 0;
}
int lockingInsert( struct lockingQueueContext *context,
void *data, size_t dataSize)
{
int result = 0;
if (context == NULL)
return -1;
assert(pthread_mutex_lock(&(context->lock)) == 0);
result = nonLockingInsert( &(context->nonLockingContext),
data, dataSize);
assert(pthread_mutex_unlock(&(context->lock)) == 0);
return result;
}
Canceling threads is another thing entirely; pthreads DOES have the
pthread_cancel() function, but if threading is a way of shooting
yourself in the foot, pthread_cancel() involves an unmarked minefield;
avoid it if you can. (For all you pthreads experts out there; do YOU
know what ALL the cancellation points defined by the API are? Better
yet, since NSThreads are based on pthreads, do you know when Cocoa will
drop out due to a cancellation point???)
A relatively safe way of canceling a thread is to create a cancel
variable and a lock to go with it (and I actually tested this code!)
#include <assert.h>
#include <pthread.h>
#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>
#include <unistd.h>
pthread_mutex_t myLock = PTHREAD_MUTEX_INITIALIZER;
bool dieNow = false;
void *threadFunc(void *arg)
{
printf("About to start loop.\n");
while (true)
{
assert(pthread_mutex_lock(&myLock) == 0);
if (dieNow)
{
assert(pthread_mutex_unlock(&myLock) == 0);
break;
}
assert(pthread_mutex_unlock(&myLock) == 0);
// Whatever processing you need to do, which may require another
// lock. Be sure, it is short! Otherwise, it will take a while
// for the thread to cancel.
}
printf("Got message to quit.\n");
return NULL;
}
int main(void)
{
pthread_t ID;
pthread_create(&ID, NULL, threadFunc, NULL);
sleep(1);
assert(pthread_mutex_lock(&myLock) == 0);
dieNow = true;
assert(pthread_mutex_unlock(&myLock) == 0);
assert(pthread_join(ID, NULL) == 0);
return 0;
}
I keep saying I'll write a book on all of this, but I never get around to
it...
Good luck,
Cem Karan
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden