macOS debugging threads

[Cromulent]

All you are doing there is allocating enough memory to store pointers, not the actual struct itself.

Try this instead:

matchinput = calloc(4, sizeof (struct input *) );
for (i = 0; i < Quad_Threads; i ++)
{
    matchinput[i] = calloc(1, sizeof (struct input));
}

P.S You shouldn't really cast the result of a malloc / calloc / realloc.

 

[chown33]

But the code did run before I tried to thread it and each call gets a separate matchinput so I'm not sure where the issue of synchronicity comes in yet. Do I need four different subroutines, one for each thread?

The code you originally posted wasn't what you've ended up with after adding the threading and the bug-fixes. So I don't know what you mean by "the code did run before I tried to thread it", since you haven't posted any code that runs without threading. Perhaps you mean something before you started making threaded modifications, but if that's what you mean, you haven't posted it, so I have no context for comparing before/after threading. The only context you've posted is after adding threads.

If you have already run the current code without threading, you need to post that code. If you haven't run the current code without thread, you should do that test now, before attempting to proceed.

I suggested that you run the current match() function without threading. I mean the one that takes a single struct input*, not the one that you originally posted, which has no possibility of working as given.

You must do this unthreaded, and look very carefully at how you are passing back the output value(s). The code you've posted so far on passing back output values is a disaster. It doesn't make sense, and is quite certainly wrong as it was last posted, which I previously pointed out (the green-hilited code).

You don't need four different subroutines.

I've already told you where to focus your attention: on the input and output parameters. In particular, you need to take a much closer look at output parameters, i.e. the calculated result that each thread is producing, and where it's storing that result, and how the memory is being created for storing that result.

I truly have no more specific recommendation, because I can't tell exactly what your output values are supposed to be. I can't figure out exactly what you want, so I can't tell you how to achieve it.

You don't have any comments for 'sd', the code involving sd is a disaster, and it's unclear what you intend to happen because you haven't explained what your output result (or results) from each thread (or the combined threads) is supposed to be. In short: no context.

We haven't even gotten to the point of determining how the threads tell the main thread that they've finished their computation. Because that's going to be another necessary element if you're going to get the results out.

 

[farmerdoug]

A quick note before the plane departs. The original code called match four times with the same data as now incorporated into the structure. Match was a float and returned sd to the original program. In principle, Ive combined all the data into the structure and sent the structure to match. Instead of returning sd, match now is supposed to put it into a structure.

Run only one thread 5 times still gives different results each time I run it.
I've attached what should be the original code with sd of difference as one routine instead of two.

I take two images; a quarter of an annulus of one image is compared at different magnifications with an other. The standard deviation of the difference between the two images is returned.

There are four structures, the output is stored in the structure send to the thread. I would think that is sufficient.

 

[farmerdoug]

Just calling match without the thread returns the same result each time but for some reason has stopped looping.

The bathrooms on the plane are busted. Still sitting. I thought you'd like to know

 

[farmerdoug]

It doesn't seem to be the output since sd_of_difference returns different values which suggests something with the input images

 

[chown33]

The code you posted as the "main copy.txt" attachment does not contain any match() function. Therefore, you cannot possibly be running the match() function in an unthreaded fashion. Unless it's in code you haven't posted.

Running sd_of_difference() in an unthreaded fashion is not proof of anything except that sd_of_difference() works. That isn't where the problem lies.

The problem lies in the way you construct your parameter structs for match(). I keep telling you to focus on how the structs are being constructed, and that you have errors in that code. If you then feed malformed parameter-blocks to match(), why would you expect that to work?

Let me rephrase this as a hypothetical, with a reasonable progression of test runs and evidence of correctness.

Suppose that sd_of_difference() works perfectly.

Next, suppose that match(), which calls sd_of_difference() does not work. Logic suggests that you look at match() and its input data, not at sd_of_difference().

Suppose that match() works perfectly if given a well-formed parameter block (i.e. a properly allocated and filled in struct input pointer). Further suppose that you have actually tested this in an unthreaded situation, and you have confirmed that you get the same results in the parameter-block output values that you got from individual runs of sd_of_difference().

Next, suppose that creating four parameter blocks and calling match() on each one in an unthreaded way fails. Where should you look? Not in match() or sd_of_difference(), because you already have evidence that they work. Logic suggests that parameter-block creation and filling in is where the problem lies.

Suppose you fix the parameter-block creation problem, and it produces correct results in an unthreaded situation. Based on this success, you decide to try a threaded version. It fails. Is it because you're creating the parameter-blocks differently? Perhaps you're trying to get results out of the parameter-blocks before the threads have completed? How would you tell the difference?

Unfortunately, you haven't done these tests, you don't have evidence that match() works unthreaded, and you haven't confirmed that parameter-block creation is correct. You also haven't posted any code that shows you're waiting for the threads to finish calculating and the results are actually available.

You don't have an unthreaded version that calls match() with a parameter block. Or if you do, you haven't posted its code.

You haven't fixed the bug I already pointed out in the construction of the parameter blocks. Or if you have, you haven't posted the revised code.

 

[lloyddean]

The include file "p1640.h" does not appear to have been provided here. So I am looking at the version as posted in one of the many other threads.

As I see it if "sd_of_difference" is being called from multi-threaded code it is VERY broken. Both 'for' loops make use the global variables "row" and "col" defined by including "p1640.h".

Both variables are modified in "main", "magnify2andshift" and "sd_of_difference".

 

[farmerdoug]

I found the row, col error last night on the plane. I also made Cromulent's changes to the memory allocation.

So at the moment I have a single problem that Chown33 alluded to. The code starts to print out results prior to the very last condition being calculated.

I'm going to check his notes, the web, etc. and see what I can learn.

P.S. My education continues despite my best efforts to keep a closed mind. I learned to run everything from Xcode. I may even get the debugger running soon. LOL
Thanks again for everybody's help.

 

[farmerdoug]

So I put pthread_join back into the code and every think is hunky dory.
Thanks.

Chown. I did do a lot of those tests you recommended on the way here.

 

[lloyddean]

I found the row, col error last night on the plane. I also made Cromulent's changes to the memory allocation.

So at the moment I have a single problem that Chown33 alluded to. The code starts to print out results prior to the very last condition being calculated.

I'm going to check his notes, the web, etc. and see what I can learn.

P.S. My education continues despite my best efforts to keep a closed mind. I learned to run everything from Xcode. I may even get the debugger running soon. LOL
Thanks again for everybody's help.

Your most prevalent problem seems to be thinking you only have one problem.

So you fixed "sd_of_difference", but what about the same issue in "magnify2andshift"?

 

[farmerdoug]

I know how many problems I have, thank you.
I haven't noticed Magnify and shift to be a problem; it is outside the threads; but I will change it anyway. All suggestions are greatly appreciated.
thanks.

 

[lloyddean]

I haven't noticed Magnify and shift to be a problem; it is outside the threads; but I will change it anyway. All suggestions are greatly appreciated.
thanks.

Sorry, I must've looked at it sideways or something.