B
Bill
Hi all,
I've got my self a bug that I am out of ideas on how to fix...
A section of my program launches a thread to handle a FIFO work buffer,
I make the fifo as a single link list, the head node is set to NULL
when the buffer is empty by the handler thread.
One or more ( typicaly 3 or 4 ) request threads are used to place
objects on to the work que.
Both the request and handler threads wait to establish ownership of a
mutex lock before adding to or freeing from the que.
The bug shows up when one of the request threads finds the work que
empty and adds it request. occasionaly the request gets clobbered by
one of the other threads.
I suspect the mutex lock is not working correctaly, but I have tested
it and can see threads having to wait for the lock ( both using gdb and
simple prints ), so I am at a loss of how a request could be getting
clobberd.
The suspect code from the handeler is:
while( epicsMutexLockOK != epicsMutexLock(*lock) ){
epicsThreadSleep(0);
printf("waiting to free\n");
}
callbackRequest(pdpvt->call);
/* Advance the que */
pport->que = que->next;
/* free the one we just finished */
fprintf(stderr,"Freeing %s\n",prec->name);
free(que->send);
free(que);
epicsMutexUnlock(*lock);
And from the requesting threads:
while( epicsMutexLockOK != epicsMutexLock(*lock)){
printf("wiat for lock:ai\n");
epicsThreadSleep(0);
}
if(pport->que){
que = pport->que;
while(que->next){
que = que->next;
}
que->next = request;
DEBUG(6,("Adding to NON empty Que\n"));
}
else{
DEBUG(6,("Adding to empty Que\n"));
pport->que = request;
if(pport->que != request){
fprintf(stderr,"Did not add to Que!!");
}
}
epicsMutexUnlock(*lock);
Any help, pointers, or pointing out of stupid mistakes ( other than my
lousy spelling ) Would be very much welcome.
--Bill
I've got my self a bug that I am out of ideas on how to fix...
A section of my program launches a thread to handle a FIFO work buffer,
I make the fifo as a single link list, the head node is set to NULL
when the buffer is empty by the handler thread.
One or more ( typicaly 3 or 4 ) request threads are used to place
objects on to the work que.
Both the request and handler threads wait to establish ownership of a
mutex lock before adding to or freeing from the que.
The bug shows up when one of the request threads finds the work que
empty and adds it request. occasionaly the request gets clobbered by
one of the other threads.
I suspect the mutex lock is not working correctaly, but I have tested
it and can see threads having to wait for the lock ( both using gdb and
simple prints ), so I am at a loss of how a request could be getting
clobberd.
The suspect code from the handeler is:
while( epicsMutexLockOK != epicsMutexLock(*lock) ){
epicsThreadSleep(0);
printf("waiting to free\n");
}
callbackRequest(pdpvt->call);
/* Advance the que */
pport->que = que->next;
/* free the one we just finished */
fprintf(stderr,"Freeing %s\n",prec->name);
free(que->send);
free(que);
epicsMutexUnlock(*lock);
And from the requesting threads:
while( epicsMutexLockOK != epicsMutexLock(*lock)){
printf("wiat for lock:ai\n");
epicsThreadSleep(0);
}
if(pport->que){
que = pport->que;
while(que->next){
que = que->next;
}
que->next = request;
DEBUG(6,("Adding to NON empty Que\n"));
}
else{
DEBUG(6,("Adding to empty Que\n"));
pport->que = request;
if(pport->que != request){
fprintf(stderr,"Did not add to Que!!");
}
}
epicsMutexUnlock(*lock);
Any help, pointers, or pointing out of stupid mistakes ( other than my
lousy spelling ) Would be very much welcome.
--Bill