Re: Cleaning up after timer_delete

["Rémi Denis-Courmont" <remi at remlab dot net>]

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/