std::queue empty() is thread safe?

  • Thread starter Thread starter Jun
  • Start date Start date
J

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
 
Jun said:
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()
}
Click to expand...

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.
 
Mihajlo Cvetanoviæ said:
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.
Click to expand...

oops... yeah got your point,

my bad i realize this after posting ~_~

thanks for your reply btw!
 
empty() may be thread safe by itself (I don't know)
Click to expand...

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.
Click to expand...

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.
Click to expand...

Those "original assumptions" don't help. The code given above contains a
synchronization error no matter how you look at it.
 
I think that most the containers provided by MFC are all not threadsafe,
you must synchronize your manipulations by yourself.
 
Back
Top