Testing if an iterator is invalid ?

[khalid302]

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]

On Jul 19, 7:12 pm, [e-mail] 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]

On Jul 20, 2:24 am, puzzlecracker <[e-mail]:

On Jul 19, 7:12 pm, [e-mail] 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]

On 7ÔÂ20ÈÕ, ÉÏÎç7ʱ38·Ö, [e-mail] wrote:

On Jul 20, 2:24 am, puzzlecracker <[e-mail]:

On Jul 19, 7:12 pm, [e-mail] 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]

dean wrote:

On 7ÔÂ20ÈÕ, ÉÏÎç7ʱ38·Ö, [e-mail] 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]

puzzlecracker writes:

On Jul 19, 7:12 pm, [e-mail] 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)

iEYEABECAAYFAkiClowACgkQx9p3GYHlUOIWAACfYY3rJ/tyKGv7NIOysFWKUDyU
L5UAn0W+FcSi1Ad1wfWq2VFxBMgsnxWJ
=+01g
-----END PGP SIGNATURE-----

[Sam]

kh*******@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)

iEYEABECAAYFAkiClt8ACgkQx9p3GYHlUOLWgQCdHL0OE4U4z2 d6Pmm534DkxKTQ
cmAAn2CcCzdpXE2NW7yLSgYeQL/5DAfP
=e7qK
-----END PGP SIGNATURE-----

[James Kanze]

On Jul 20, 1:12 am, [e-mail] 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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[khalid302]

On Jul 20, 4:07 am, Ian Collins <[e-mail]:

dean wrote:

On 7ÔÂ20ÈÕ, ÉÏÎç7ʱ38·Ö, [e-mail] 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.