This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Cleaning up after timer_delete
Le dimanche 26 juillet 2009 00:24:09 Carlos O'Donell, vous avez écrit :
> 2009/7/25 Rémi Denis-Courmont <remi@remlab.net>:
> > I want to know that there threads are _terminated_ so that I can release
> > data that those threads use. I cannot release data if threads are still
> > using it, regardless of when they were created.
> >
> > And I cannot release data from the timer callback either because I do not
> > know which thread is "the last one". There could be *more* than one
> > thread still running after timer_delete() afterall.
>
> After reading the code more I don't think you can know when the
> threads have terminated, but I don't know that you need this
> information.
Right.
> I think the solution is going to be the other way around, the callback
> has to know you are about to delete the timer and avoid touching the
> resource.
The only piece of data that the lock has is the pointer. That pointer, as far
as I know, cannot be changed through the life time of the timer, which
excludes changing it to some "error" value.
> Isn't this simply a synchronization problem, you have an unknown
> number of threads using a single resource you want to delete.
>
> Protect the resource with a lock?
To protect the resource with a lock, I need to create a new resource that
contains a lock and a pointer to the original resource:
struct safe_resource
{
pthread_mutex_t lock;
struct foo *resource;
//bool deleted;
};
Now when can I delete the new lock and the safe_resource structure? They have
to be allocated somewhere... Adding a lock just moves the problem.
--
Rémi Denis-Courmont
http://www.remlab.net/