Re: Share a read-only std::list between two threads

On Mar 3, 11:41 am, Marcin 'Qrczak' Kowalczyk <qrc...@xxxxxxxxxx>
wrote:

In theory yes, but a hash table which cares about threads emulates
safety guarantees of simple C types: concurrent reads should be safe.

So the questions is, do you have a hash table which cares about
threads?

I suspect that any serious C++ implementation which can be used with
multiple threads at all makes such guarantee, even if implicitly.

I would hope so. Threads and C++ are mature enough now that I think we
should be able to expect standard library types to work like normal
types. Hopefully, the number of exceptions to this rule will be small
and make sense.

I'm not so sure how far we've come on this front.

DS
.

Relevant Pages

  • Re: Share a read-only std::list between two threads
    ... > safety guarantees of simple C types: ... do you have a hash table which cares about ...
    (comp.programming.threads)
  • Re: Share a read-only std::list between two threads
    ... do you have a hash table which cares about ... A single object is thread safe for reading from multiple threads. ...
    (comp.programming.threads)
  • Re: dentry bloat.
    ... it should be safe to at least do the name hash and parent ... comparison without holding any lock (since even if they are invalidated by ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: dentry bloat.
    ... it should be safe to at least do the name hash and parent ... > comparison without holding any lock (since even if they are invalidated by ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: if SHA1 and MD5 are cracked...?
    ... > cryptographic applications use hash algorithms for key generation. ... FreeBSD uses MD5 over DES for the /etc/master.password file under the ... PGP and GPG use a hash of the private key passphrase to encrypt ... safe from script kiddies but possibly breakable by government agencies. ...
    (comp.unix.bsd.freebsd.misc)