Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c++ > #88231

Re: Greatly simplify multithreaded access to global object

From Paavo Helde <eesnimi@osa.pri.ee>
Newsgroups comp.lang.c++
Subject Re: Greatly simplify multithreaded access to global object
Date 2022-12-22 23:01 +0200
Organization A noiseless patient Spider
Message-ID <to2gjt$1fced$1@dont-email.me> (permalink)
References <b5d4afb7-1e6d-4753-bbde-963f9331720bn@googlegroups.com>

Show all headers | View raw


22.12.2022 21:41 Frederick Virchanza Gotham kirjutas:
> 
> I don't know if I've re-invented the wheel here but I can't remember having seen something like this in the C++ standard library nor Boost nor wxWidgets.
> 
> Let's say we have a multi-threaded program, it has a main GUI thread and five worker threads, giving a total of six threads.
> 
> The program at all times has a status string, which is a global 'std::string' object. All six threads read and write the global status string.

[snipped implementation with a proxy containing a mutex lock]

I have done such things in the past, but in retrospect this was not the 
best idea, mainly because it hides the thread-locking step and makes the 
code harder to follow and verify for correctness.

Nowadays I would just make a dedicated member function of the 
StatusManager class which would just append to the string under a mutex 
lock. If it appears this is becoming a bottleneck, one can redesign the 
member function to e.g. move the appended string pieces to some kind of 
fast inter-thread queue. With a locked proxy like in your design it 
would be harder to rewrite the functionality.

Back to comp.lang.c++ | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Greatly simplify multithreaded access to global object Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-12-22 11:41 -0800
  Re: Greatly simplify multithreaded access to global object Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-12-22 11:51 -0800
  Re: Greatly simplify multithreaded access to global object scott@slp53.sl.home (Scott Lurndal) - 2022-12-22 20:11 +0000
    Re: Greatly simplify multithreaded access to global object Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-12-22 12:25 -0800
    Re: Greatly simplify multithreaded access to global object "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-22 15:39 -0800
    Re: Greatly simplify multithreaded access to global object "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-22 15:42 -0800
  Re: Greatly simplify multithreaded access to global object David Brown <david.brown@hesbynett.no> - 2022-12-22 21:41 +0100
    Re: Greatly simplify multithreaded access to global object Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-22 23:05 +0200
      Re: Greatly simplify multithreaded access to global object David Brown <david.brown@hesbynett.no> - 2022-12-23 00:11 +0100
  Re: Greatly simplify multithreaded access to global object Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-22 23:01 +0200
  Re: Greatly simplify multithreaded access to global object Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-12-31 07:41 -0800
    Re: Greatly simplify multithreaded access to global object Muttley@dastardlyhq.com - 2022-12-31 16:02 +0000
      Re: Greatly simplify multithreaded access to global object David Brown <david.brown@hesbynett.no> - 2022-12-31 18:45 +0100

csiph-web