If you are using VC and you are deadlocking in the static lock used by the
map collection, you should be aware that there are fixes at the DinkumWare
site which remove this static lock altogether.

http://www.dinkumware.com/vc_fixes.html


"Rusted Nail" <lisa66@nettaxi.com> wrote in message news:Mc0y4.2334
> I wonder if STL uses any synchronization?
> I'm getting deadlock and some of my colleagues said that it's because of
> conflict between global lock used implicitly by std::map and global mutex
> used by my program.




======================================= MODERATOR'S COMMENT:
 This post has been approved because of its applicability to
people
trying to write Standard conforming C++ with VC.  Please take any
VC-specific
followups to e-mail or to another newsgroup.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Yes, MS implementation of stl does use global lock in its container classes
> I wonder if STL uses any synchronization?
> I'm getting deadlock and some of my colleagues said that it's because of
> conflict between global lock used implicitly by std::map and global mutex
> used by my program.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I wonder if STL uses any synchronization?
I'm getting deadlock and some of my colleagues said that it's because of
conflict between global lock used implicitly by std::map and global mutex
used by my program.

Best regards,
Alex

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

That will depend on your implementation.  The one shipped with MSVC
does some synchronization, but I think your colleagues are wrong
unless your using objects incorrectly across threads (meaning you need
to be synchronization them).  How do they think your program is
getting access to the STL implementations mutex, semaphore,
critical_section, whatever?

On Sat, 11 Mar 2000 03:24:16 CST, "Rusted Nail" <lisa66@nettaxi.com>
wrote:

>I wonder if STL uses any synchronization?
>I'm getting deadlock and some of my colleagues said that it's because of
>conflict between global lock used implicitly by std::map and global mutex
>used by my program.
>
>Best regards,
>Alex
>
>---
>[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
>[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
>[              --- Please see the FAQ before posting. ---               ]
>[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Rusted Nail" <lisa66@nettaxi.com> wrote in message
news:Mc0y4.2334$Of2.37827@typhoon.ne.mediaone.net...
> I wonder if STL uses any synchronization?

If you're using UNIX or Windows, you can assume the answer
is yes. It doesn't have to, since the standard say nothing about
threads, but I suspect most implementors on multi-threaded
platforms will try to make their library thread-safe simply out
of professional pride.

> I'm getting deadlock and some of my colleagues said that it's
> because of conflict between global lock used implicitly by
> std::map and global mutex used by my program.

One possible scenario...

1  You called a function in std::map, which claims the lock.
2  That function needs to create a new entry, and constructs
    an object of one of your classes.
3  The construction of that object (in your code) indirectly tries
    to do something that claims your global mutex.
4  Another thread, currently holding the mutex, performs a map
    operation.

You now have two threads, each waiting for a resource held
exclusively by the other.

Whose fault is this? Well, I haven't seen the source code for your
map class, but it presumably holds its global mutex for as little
time as the author thought possible. However, all containers have
to create elements at some point, and that gives user-defined code
a chance to run. If that code (the constructor for your element class)
claims other locks, then the potential for deadlock is inescapable.

I suspect it is impossible to write std::map code that releases the
lock whilst calling the constructor for the element class. Consider
an insertion...

    {
        // decide whether and where to insert
        // create new Element
        // connect it all up to the map.
    }

If we release the lock for step 2, then all the decisions we made
in step 1 could be invalidated before we re-claim it for step 3.
(Another thread could remove every element in the map.) It follows
that the only safe times to allocate a new element are before and
after the main body of the method. We can't do it beforehand, since
we don't know whether we need to or not. We can't do it at the end,
because after creating the new element, we still need to hook it into
the collection. It would seem to be impossible.

I conclude that any class which will be stored in a collection must
have a constructor that claims no synchronisation locks. (This
probably applies to the copy-constructor, assignment operator
and destructor, but I haven't considered them here.)
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]