Multithreaded application

Question

Hi all,
I know that it is a fairly complicated matter and I have read almost all online sources on the question
but still may be I am missing something. I have written an application for a digital camera which
also supports continuous shooting mode(20-30 or more pictures taken very fast after one another).
I decided to handle the image transfer with a multithread approach. The beta version of my
application has been tested for a couple of months and there are many complains that the
application crashes or is stuck at some point, this happens only when images are being transfered in
the camera's continuous mode. Below is the piece of code where the threads are being created and
unleashed to do the work(for the most part I am building the future image files' names and acquiring
the information from the camera which is in another class(CameraAccess)). There are also few calls
to my main thread where the GUI should be updated.
-(void) transferRequest
//Should I use a second run loop, the apple documentation diverges here! Answer: No.
self setReleaseInProgress:YES;<br/> NSThread* currThread = [[NSThread alloc] initWithTarget:self selector: @selector(runTransfer:) object:nil];<br/> self setTransferThread: currThread;<br/> ;<br/> //[currThread release];<br/>}<br/><br/>-(void) runTransfer: (id) sender<br/>{<br/> NSRecursiveLock* theLock = [[NSLock alloc] init];<br/> ;<br/> <br/> NSAutoreleasePool pool = [[NSAutoreleasePool alloc] init];<br/> NSString folderPath = [[[NSString alloc] init] autorelease]; <br/> NSString* fileName = [[[NSString alloc] init] autorelease]; <br/> NSString* saveFileName = [[[NSString alloc] init] autorelease]; <br/> <br/> IOPMAssertionID assertionID;<br/> IOReturn success = IOPMAssertionCreate(kIOPMAssertionTypeNoDisplaySleep, kIOPMAssertionLevelOn, &amp;assertionID); <br/> if (success == kIOReturnSuccess)<br/> {<br/> // The lines beneath assure that the system will not go to sleep during the transfer <br/> // kIOPMAssertionTypeNoDisplaySleep prevents display sleep,<br/> // kIOPMAssertionTypeNoIdleSleep prevents idle sleep<br/> numOfActiveThreads++;<br/> <br/> if(sendContinuousReleaseEnd)<br/> {<br/> if(self releaseCam:13)<br/> {<br/> NSNumber* boolean0 = NSNumber numberWithBool: FALSE;<br/> self performSelectorOnMainThread: @selector(setPropertySendContinuousReleaseEnd:) withObject: boolean0 waitUntilDone: YES;<br/> }<br/> }<br/> NSNumber* boolean = NSNumber numberWithBool:TRUE;<br/> self performSelectorOnMainThread: @selector(setPropertyIsTransferInProgress:) withObject: boolean waitUntilDone: YES;<br/> <br/> UInt8* resultPtr = NULL; <br/> resultPtr = malloc(156); <br/> [[self camAccess] copyObjectPropertyDictionary: resultPtr];<br/> UInt32 numPics = 0;<br/> UInt32 tmp3 = 0;<br/> UInt32 tmp4 = 0;<br/> tmp3 = resultPtr[48];<br/> tmp4 = resultPtr[49];<br/> if(tmp3 &gt; 0 || tmp4 &gt; 0)<br/> {<br/> numPics = tmp3 | (tmp4&lt;&lt;8);<br/> tmp3 = resultPtr[50];<br/> numPics = numPics | (tmp3&lt;&lt;16);<br/> tmp3 = resultPtr[51];<br/> numPics = numPics | (tmp3&lt;&lt;24);<br/> }<br/> NSNumber* integer00 = NSNumber numberWithInt: numPics;<br/> self performSelectorOnMainThread: @selector(setPropertyPicsInQueue:) withObject: integer00 waitUntilDone: YES;<br/> <br/> if(picsInQueue == 1)<br/> {<br/> NSNumber* integer0 = NSNumber numberWithInt: 1;<br/> self performSelectorOnMainThread: @selector(setPropertyNumOfPicsToSend:) withObject: integer0 waitUntilDone: YES;<br/> }<br/> else<br/> {<br/> if(numOfPicsToSend &gt;= picsInQueue)<br/> {<br/> <br/> }<br/> else<br/> {<br/> NSNumber* integer = NSNumber numberWithInt: picsInQueue;<br/> self performSelectorOnMainThread: @selector(setPropertyNumOfPicsToSend:) withObject: integer waitUntilDone: YES;<br/> }<br/> }<br/> <br/> if( == nil || [[folderSettings pictureNewFileName] isEqual:@""])<br/> {<br/> NSString* string = [[[NSString alloc] initWithString: @"Picture"] autorelease];<br/> self performSelectorOnMainThread: @selector(setFolderSettingsPictureNewFileName:) withObject: string waitUntilDone: YES;<br/> }<br/><br/> /file name and extension/<br/> NSData* info = [[[NSData alloc] initWithBytes: resultPtr length:156] autorelease]; <br/> NSRange range;<br/> range.length = 27;<br/> range.location = 53;<br/> NSData* subDataInfo = info subdataWithRange: range;//alloc?! autorelease?!<br/> NSString* fileNameFromBytes = [[[NSString alloc] initWithBytes: length: 27 encoding: NSUTF16LittleEndianStringEncoding] autorelease]; length: 27 encoding: NSUTF16LittleEndianStringEncoding];<br/> //Case differentiation, is the picture DNG or JPG<br/> NSArray* listItems = [[[NSArray alloc] init] autorelease]; <br/> listItems = [fileNameFromBytes componentsSeparatedByString:@"."];<br/> NSString* fExtension = [[[NSString alloc] initWithString:[listItems objectAtIndex:[listItems count] - 1]] autorelease]; <br/> if([fExtension caseInsensitiveCompare: @"DNG

Answer 1

artOf... wrote:
The main goal is to leave the GUI active(to some extend) during this image transfer(this is also
done and working) - answer to your question #1, may be I do not specifically need multithreading
may be what you mentioned below 'producer/consumer model' is the way to go. I simply do not
have any idea how to implement it.
My first suggestion is to change your code a bit so that you can easily turn the multithreading on or off, just so you can play around with some non-multithreading options. Basically, that just means adding some code where you call the thread main method directly instead of via NSThread. Then you can comment out one way or the other to play around.
Producer/consumer (and and dozen other names it may be called) is one of the easiest ways to implement multithreading. Actually, it has nothing to do with threading. It is just an architecture to use a queue of object to be worked. There is some producer that adds objects to the queue and a consumer that removes them, and works on them. You can run your consumer in a separate thread and the producer will never get backed up or have to wait on it. The only locking involved is to ensure mutual exclusion when adding to or removing from the queue.
To answer your question #2, there is no specific function call
that is slow or blocking, the application simply crashes at some point(memory generated crashes
not on one place in the code every time, but 3-4 different errors which i do not grasp).
But it is crashing due to the thread problems. What happens if you don't have any multithreading? Then were is the slowness and/or blocking?
Question #3 - I have read about synchronous and asynchronous function calls but that is also something that I never
used before(may be to receive my events from the camera, but this was a ready example and I
used it directly.)
The problem is that most hardware interaction is designed to use asynchronous operations. Otherwise, the OS locks up due to hardware and really bad things start to happen. See MacOS 7 for details. Unfortunately, many hardware interaction examples use synchronous operations because they are easier to show and understand.
Q. #4 - the recursive lock was just a test, normally I have just NSLock at the same
point(the reason for this test was that when I was using NSLock, rarely but still, I receive the crash error:
* -[NSRecursiveLock finalize]: lock (<NSRecursiveLock: 0x1267610> '(null)') finalized while still in use).
That lock, recursive or not, is not a good one. A producer/consumer model would eliminate that lock because you would only ever have a single worker thread.
I just thought that those wrapper
methods are needed since I thought I can't omit the performSelector methods and those need @selector:
so I just invented the approach to communicate with my camera object (refered to by self in the code since
the code is in the Camera.m class). Also I make some calls to a class CameraAccess.m which is my direct
communication with the camera, should I put those in performSelector as well or should I just remove all
occurances of performSelector if possible?
The only time you really need to perform a selector on the main thread is when you need to update the interface. If you are talking with hardware using APIs that may not be reentrant, you just need to make sure you aren't doing that from multiple threads. You don't necessarily have to do it from the main thread.
As I said, the application is working, the images are transfered,
just in rare occasions there are crashes which is bad enough but still...
With threads, getting it working 99% of the time may mean you have done it horribly wrong. That 1% of the time it crashes is often with hardware, which may leave it in a corrupt state.
I am also interested in the 'producer/consumer model' do you have a 'simple' example of an interaction of
such a thread approach?
It is basically just a queue. Create a wrapper to add to or remove from the queue that has some sort of locking mechanism. The built-in @synchronized directive is very handy for that. I may have posted a simple example here a couple of years ago. Do a search for my posts with the word "multithreaded" or something.