469,889 Members | 1,262 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,889 developers. It's quick & easy.

std::queue empty() is thread safe?

Jun
hi,

just want to know if std::queue empty() is thread safe (running on 2 or more
thread)... so i can do,

if( !queue.empty() )
{
lock()
....
unlock()
}

instead of...

lock()
if( !queue.empty() )
{
....
}
unlock()

thanks in advance
Nov 17 '05 #1
8 3586
Jun wrote:
just want to know if std::queue empty() is thread safe (running on 2 or more
thread)... so i can do,

if( !queue.empty() )
{
lock()
....
unlock()
}


empty() may be thread safe by itself (I don't know), but this code
actually isn't. Consider the situation where queue isn't empty on "if"
but gets empty on "lock". To avoid this situation you must lock() before
querying the queue. If you are worrying about performance of
"unnecessary" lock then you have made two errors in judgment:

1. lock *is* necessary, and
2. performance loss is so minimal that we shouldn't even consider it.

Maybe in your case queue won't ever go from non-empty to empty between
"if" and "lock", because the code in the if branch is the only place
where this can happen. This shouldn't stop you from making robust code
that will work even when original assumptions are changed.
Nov 17 '05 #2
Jun wrote:
just want to know if std::queue empty() is thread safe (running on 2 or more
thread)... so i can do,

if( !queue.empty() )
{
lock()
....
unlock()
}


empty() may be thread safe by itself (I don't know), but this code
actually isn't. Consider the situation where queue isn't empty on "if"
but gets empty on "lock". To avoid this situation you must lock() before
querying the queue. If you are worrying about performance of
"unnecessary" lock then you have made two errors in judgment:

1. lock *is* necessary, and
2. performance loss is so minimal that we shouldn't even consider it.

Maybe in your case queue won't ever go from non-empty to empty between
"if" and "lock", because the code in the if branch is the only place
where this can happen. This shouldn't stop you from making robust code
that will work even when original assumptions are changed.
Nov 17 '05 #3
Jun

"Mihajlo Cvetanović" <ma*@RnEeMtOsVeEt.co.yu> wrote in message
news:uS**************@TK2MSFTNGP09.phx.gbl...
Jun wrote:
just want to know if std::queue empty() is thread safe (running on 2 or
more thread)... so i can do,

if( !queue.empty() )
{
lock()
....
unlock()
}


empty() may be thread safe by itself (I don't know), but this code
actually isn't. Consider the situation where queue isn't empty on "if" but
gets empty on "lock". To avoid this situation you must lock() before
querying the queue. If you are worrying about performance of "unnecessary"
lock then you have made two errors in judgment:

1. lock *is* necessary, and
2. performance loss is so minimal that we shouldn't even consider it.

Maybe in your case queue won't ever go from non-empty to empty between
"if" and "lock", because the code in the if branch is the only place where
this can happen. This shouldn't stop you from making robust code that will
work even when original assumptions are changed.


oops... yeah got your point,

my bad i realize this after posting ~_~

thanks for your reply btw!
Nov 17 '05 #4
Jun

"Mihajlo Cvetanović" <ma*@RnEeMtOsVeEt.co.yu> wrote in message
news:uS**************@TK2MSFTNGP09.phx.gbl...
Jun wrote:
just want to know if std::queue empty() is thread safe (running on 2 or
more thread)... so i can do,

if( !queue.empty() )
{
lock()
....
unlock()
}


empty() may be thread safe by itself (I don't know), but this code
actually isn't. Consider the situation where queue isn't empty on "if" but
gets empty on "lock". To avoid this situation you must lock() before
querying the queue. If you are worrying about performance of "unnecessary"
lock then you have made two errors in judgment:

1. lock *is* necessary, and
2. performance loss is so minimal that we shouldn't even consider it.

Maybe in your case queue won't ever go from non-empty to empty between
"if" and "lock", because the code in the if branch is the only place where
this can happen. This shouldn't stop you from making robust code that will
work even when original assumptions are changed.


oops... yeah got your point,

my bad i realize this after posting ~_~

thanks for your reply btw!
Nov 17 '05 #5
On Mon, 04 Jul 2005 15:11:29 +0200, Mihajlo Cvetanović wrote:
Jun wrote:
just want to know if std::queue empty() is thread safe (running on 2 or more
thread)... so i can do,

if( !queue.empty() )
{
lock()
....
unlock()
}
empty() may be thread safe by itself (I don't know)


It isn't. Note also that for the sequence above to have any chance of
working, lock/unlock would have to operate on the same mutex as std::queue
uses internally, if it used a mutex internally, which it doesn't.
but this code
actually isn't. Consider the situation where queue isn't empty on "if"
but gets empty on "lock". To avoid this situation you must lock() before
querying the queue. If you are worrying about performance of
"unnecessary" lock then you have made two errors in judgment:

1. lock *is* necessary, and
2. performance loss is so minimal that we shouldn't even consider it.
Point (2) doesn't necessarily apply.
Maybe in your case queue won't ever go from non-empty to empty between
"if" and "lock", because the code in the if branch is the only place
where this can happen. This shouldn't stop you from making robust code
that will work even when original assumptions are changed.


Those "original assumptions" don't help. The code given above contains a
synchronization error no matter how you look at it.

--
Doug Harrison
Microsoft MVP - Visual C++
Nov 17 '05 #6
On Mon, 04 Jul 2005 15:11:29 +0200, Mihajlo Cvetanović wrote:
Jun wrote:
just want to know if std::queue empty() is thread safe (running on 2 or more
thread)... so i can do,

if( !queue.empty() )
{
lock()
....
unlock()
}
empty() may be thread safe by itself (I don't know)


It isn't. Note also that for the sequence above to have any chance of
working, lock/unlock would have to operate on the same mutex as std::queue
uses internally, if it used a mutex internally, which it doesn't.
but this code
actually isn't. Consider the situation where queue isn't empty on "if"
but gets empty on "lock". To avoid this situation you must lock() before
querying the queue. If you are worrying about performance of
"unnecessary" lock then you have made two errors in judgment:

1. lock *is* necessary, and
2. performance loss is so minimal that we shouldn't even consider it.
Point (2) doesn't necessarily apply.
Maybe in your case queue won't ever go from non-empty to empty between
"if" and "lock", because the code in the if branch is the only place
where this can happen. This shouldn't stop you from making robust code
that will work even when original assumptions are changed.


Those "original assumptions" don't help. The code given above contains a
synchronization error no matter how you look at it.

--
Doug Harrison
Microsoft MVP - Visual C++
Nov 17 '05 #7
I think that most the containers provided by MFC are all not threadsafe,
you must synchronize your manipulations by yourself.
Nov 17 '05 #8
I think that most the containers provided by MFC are all not threadsafe,
you must synchronize your manipulations by yourself.
Nov 17 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Philip V Pham | last post: by
5 posts views Thread by Gernot Frisch | last post: by
3 posts views Thread by Andy | last post: by
reply views Thread by Jun | last post: by
reply views Thread by ecestd | last post: by
29 posts views Thread by NvrBst | last post: by
19 posts views Thread by =?ISO-8859-1?Q?Nordl=F6w?= | last post: by
1 post views Thread by Waqarahmed | last post: by
reply views Thread by Salome Sato | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.