The trick is just to see if the container is currently being used or not
and if not then perform cleanups, etc.:

namespace thread_safe
{

template <class T>
     class circular : protected std::list<T>
     {
         [...]

         template <class... Args>
             void emplace(Args &&... args)
             {
                 if (mutex_.try_lock())
                 {
                     for (; capacity_ < size_; -- size_)
                         std::list<T>::pop_front();

 
std::list<T>::emplace_back(std::forward<Args>(args)...);

                     ++ size_;

                     mutex_.unlock();
                 }
                 else
                 {
                     std::scoped_lock lock(mutex_);

 
std::list<T>::emplace_back(std::forward<Args>(args)...);

                     ++ size_;
                 }
             }
     };
}


On 2/23/24 12:30, Sebastian Wittmeier via Std-Proposals wrote:
> The consensus for programming languages (not just C++) is that the
> granularity of locking single member function calls with a mutex is
> typically too small for real-world applications. You need transactions
> spanning several calls to the same and/or different containers and data
> structures to get again a valid state.
>
> Protecting all individual member functions just for the duration of the
> call would not be thread-safe.
>
> Doing it in addition to another overarching mutex would be worse
> performance-wise and could lead many developers into a false sense of
> security. So they would assume the code is thread-safe, when actually it
> is not.
>
> Java did it wrong once in the past, but then reversed course.
>
> -----Ursprüngliche Nachricht-----
> *Von:* David G. Pickett via Std-Proposals
> <std-proposals_at_[hidden]>
> *Gesendet:* Fr 23.02.2024 18:21
> *Betreff:* Re: [std-proposals] High Performance Thread-Safe C++
> *An:* std-proposals_at_[hidden];
> *CC:* David G. Pickett <dgpickett_at_[hidden]>;
> It'd be nice if the language had a way to say that a particular
> container *instance* needs to be thread safe, so all methods are
> mutex protected. The developer could add a reserved word in the
> declaration. This way, users are not accidentally using a mutex
> unnecessarily. The compiler can add the mutex lock to all methods
> when invoked, somewhat like a MACRO but less global. We don't want
> to be like Java, and have to remember which container name is
> synchronized, e.g ArrayList, Vector; StringBuffer, StringBuilder, or
> hve duffers using a synchronized container when not needed.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
>

-- 
Logo <https://www.fornux.com/>  
*Phil Bouchard*  facebook icon
<https://www.linkedin.com/in/phil-bouchard-5723a910/> 
Founder & CEO
T: (819) 328-4743
E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com>
320-345 de la Gauchetière Ouest| Montréal (Qc), H2Z 0A2 Canada
Banner <https://goglobalawards.org/> Le message ci-dessus, ainsi que les
documents l'accompagnant, sont destinés uniquement aux personnes
identifiées et peuvent contenir des informations privilégiées,
confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce
message par erreur, veuillez le détruire.
This communication (and/or the attachments) is intended for named
recipients only and may contain privileged or confidential information
which is not to be disclosed. If you received this communication by
mistake please destroy all copies.