Testing if an iterator is invalid ?

[khalid302@gmail.com]

I'm writing a multi-threaded application where one thread waits for a
certain std::set element to be deleted by another thread.

The waiting thread already has an iterator pointing at the element
that has to be deleted. After the other thread deletes this element,
the iterator will become invalid.

Is there a way to know if a certain iterator is invalid ?

[puzzlecracker]

Re: Testing if an iterator is invalid ?

On Jul 19, 7:12 pm, khalid...@gmail .com wrote:

I'm writing a multi-threaded application where one thread waits for a
certain std::set element to be deleted by another thread.
>
The waiting thread already has an iterator pointing at the element
that has to be deleted. After the other thread deletes this element,
the iterator will become invalid.
>
Is there a way to know if a certain iterator is invalid ?

You can assign NULL to the deleted element, and have the waiting
thread check for null-ness after the waiting time.

[khalid302@gmail.com]

Re: Testing if an iterator is invalid ?

On Jul 20, 2:24 am, puzzlecracker <ironsel2...@gm ail.comwrote:

On Jul 19, 7:12 pm, khalid...@gmail .com wrote:
>

I'm writing a multi-threaded application where one thread waits for a
certain std::set element to be deleted by another thread.

>

The waiting thread already has an iterator pointing at the element
that has to be deleted. After the other thread deletes this element,
the iterator will become invalid.

>

Is there a way to know if a certain iterator is invalid ?

>
You can assign NULL to the deleted element, and have the waiting
thread check for null-ness after the waiting time.

It's an std::set<intso I'll assign a -1 instead of a NULL.

The waiting thread can then remove that element. The problem now
becomes, there could more than one thread waiting for the same element
to be deleted, which one of them should do the actual deletion.

There isn't a way to check if an iterator is invalid, right ?

Thanks for your idea

[dean]

Re: Testing if an iterator is invalid ?

On 7ÔÂ20ÈÕ, ÉÏÎç7ʱ38·Ö, khalid...@gmail .com wrote:

On Jul 20, 2:24 am, puzzlecracker <ironsel2...@gm ail.comwrote:
>

On Jul 19, 7:12 pm, khalid...@gmail .com wrote:

>

I'm writing a multi-threaded application where one thread waits for a
certain std::set element to be deleted by another thread.

>

The waiting thread already has an iterator pointing at the element
that has to be deleted. After the other thread deletes this element,
the iterator will become invalid.

>

Is there a way to know if a certain iterator is invalid ?

>

You can assign NULL to the deleted element, and have the waiting
thread check for null-ness after the waiting time.

>
It's an std::set<intso I'll assign a -1 instead of a NULL.
>
The waiting thread can then remove that element. The problem now
becomes, there could more than one thread waiting for the same element
to be deleted, which one of them should do the actual deletion.
>
There isn't a way to check if an iterator is invalid, right ?
>
Thanks for your idea

I think you should choose some other thread synchronization mechanism
rather than checking the iterator, mutex may be a good choice

[Ian Collins]

Re: Testing if an iterator is invalid ?

dean wrote:

On 7ÔÂ20ÈÕ, ÉÏÎç7ʱ38·Ö, khalid...@gmail .com wrote:

>>
>The waiting thread can then remove that element. The problem now
>becomes, there could more than one thread waiting for the same element
>to be deleted, which one of them should do the actual deletion.
>>
>There isn't a way to check if an iterator is invalid, right ?
>>
>Thanks for your idea

>
I think you should choose some other thread synchronization mechanism
rather than checking the iterator, mutex may be a good choice

Better to a synchronisation object such as a condition variable or
semaphore.

Never use STL objects for thread synchronisation .

--
Ian Collins.

[Sam]

Re: Testing if an iterator is invalid ?

puzzlecracker writes:

On Jul 19, 7:12 pm, khalid...@gmail .com wrote:

>I'm writing a multi-threaded application where one thread waits for a
>certain std::set element to be deleted by another thread.
>>
>The waiting thread already has an iterator pointing at the element
>that has to be deleted. After the other thread deletes this element,
>the iterator will become invalid.
>>
>Is there a way to know if a certain iterator is invalid ?

>
>
You can assign NULL to the deleted element, and have the waiting
thread check for null-ness after the waiting time.

Bullshit.

Once an element is deleted from a collection, the element no longer exist.
It cannot be set to NULL, 3.1415926, or any other value, after it is removed
from a std::set.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAki ClowACgkQx9p3GY HlUOIWAACfYY3rJ/tyKGv7NIOysFWKU DyU
L5UAn0W+FcSi1Ad 1wfWq2VFxBMgsnx WJ
=+01g
-----END PGP SIGNATURE-----

[Sam]

Re: Testing if an iterator is invalid ?

khalid302@gmail .com writes:

I'm writing a multi-threaded application where one thread waits for a
certain std::set element to be deleted by another thread.
>
The waiting thread already has an iterator pointing at the element
that has to be deleted. After the other thread deletes this element,
the iterator will become invalid.
>
Is there a way to know if a certain iterator is invalid ?

No.

You will need to implement some other synchronization mechanism.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAki Clt8ACgkQx9p3GY HlUOLWgQCdHL0OE 4U4z2d6Pmm534Dk xKTQ
cmAAn2CcCzdpXE2 NW7yLSgYeQL/5DAfP
=e7qK
-----END PGP SIGNATURE-----

[James Kanze]

Re: Testing if an iterator is invalid ?

On Jul 20, 1:12 am, khalid...@gmail .com wrote:

I'm writing a multi-threaded application where one thread waits for a
certain std::set element to be deleted by another thread.

The waiting thread already has an iterator pointing at the element
that has to be deleted. After the other thread deletes this element,
the iterator will become invalid.

Is there a way to know if a certain iterator is invalid ?

No.

The suggestions of assigning NULL to the iterator (which
probably won't compile) or assigning something through it (which
is undefined behavior, and will likely lead to a core dump) are
just bullshit. Ian is the only one who really got this right:
you must use a special synchronization object, supported by your
OS. Under Unix, pthread_cond_t; under Windows, I don't know.
Or better yet, use the conditional object in Boost threads.

Without external synchronization by the OS (or perhaps some
platform specific assembler code), you have undefined behavior.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[khalid302@gmail.com]

Re: Testing if an iterator is invalid ?

On Jul 20, 4:07 am, Ian Collins <ian-n...@hotmail.co mwrote:

dean wrote:

On 7ÔÂ20ÈÕ, ÉÏÎç7ʱ38·Ö, khalid...@gmail .com wrote:

>

The waiting thread can then remove that element. The problem now
becomes, there could more than one thread waiting for the same element
to be deleted, which one of them should do the actual deletion.

>

There isn't a way to check if an iterator is invalid, right ?

>

Thanks for your idea

>

I think you should choose some other thread synchronization mechanism
rather than checking the iterator, mutex may be a good choice

>
Better to a synchronisation object such as a condition variable or
semaphore.

I have been doing just that, however, I was using a single condition
variable for the whole std::set. So it was one of two ways:

Each time this single condition variable is broadcast, each waiting
thread calls set.find() for the element value its waiting for the
deletion of. But this means so many false set.find() calls.

Now I resorted to using a condition variable for each std:set element
and do a broadcast upon the deletion of this certain element.

However, if I was able to check for the validity of the iterator pre-
acquired by the waiting thread with find(). I wouldn't have had to
create multiple condition variables.

Thanks for your help

Never use STL objects for thread synchronisation .
>
--
Ian Collins.