Originally Posted by xpi0t0s View Post
What is the program doing wrong?
You've got a mutex on thread 2 but don't you need one on thread 1 as well? What's to stop threads 1&2 operating on the same bit of memory?
What is the significance of 4136 (in the memset call)? If sizeof(struct CaptureBuffer)==4136, why not use sizeof(struct CaptureBuffer) instead, and if it isn't, what do you think will happen?
4136*100000 = 413 600 000 not counting other memory needed for pointers and such. Does your program have over 394MB to play with?

Well this program works between two network interfaces. It contains two threads, capture and sender. Capture thread captures packets at first interface and stores in a linked list and the other thread retrieves the packets from the list and sends through the other interface and the linked list node is removed. The thing that i have to do is to apply delay on the captured packet before they are stored using linked list. These packets are sent by reading their play out time that is the time stamp of the packet when it is captured plus the amount of delay time added into the time stamp. Such that a kind of delay is added to the packets.

I guess i had mutex on thread one as well. Here one thing, I am using two different mutex variable. I mean, one for each thread. Where it should be implemented and will it be useful in this application where continuously packet are captured and sent. I have to do it urngently so I can't think of any other solution at this point of time and I am new to C and for the first time I implemented pthreads and linked list stuff.

4136 is size of the CaptureBuffer and sizeof(CaptureBuffer) can be used instead. You are right.

I can't understand the remaining contents of your post. What is the shortfall if 4136 is used. I did not get it. I'll change it with sizeof(CaptureBuffer). This is not the problem. How the two process can be synchronized is the main issue here regardless of the number of packets coming to the interface.

Thanks for the post and appreciate your further replies.