0

Often I use pthread's mutex only to protect a section, for instance an asynchronous timed draw function which pick the objects to draw from a list where objects can be deleted.

Is there any alternative? (libc's atomic types?)

edit

A more simple example, no lists.

I've a 3D model viewer using OpenGL, the draw function is called by a timer. The user can select another file to view with keyboard or mouse, but destroying the data of the current model from memory while drawing will obviously cause a segmentation.

Currently I'm using pthread_mutex_trylock in the draw function and pthread_mutex_lock where the object is destroyed and the new is loaded.

The only lock-free alternative I see would be to load the new object in memory before destroying the old, but IMHO that would add some overhead, I just need some lock unlock primitive (eventually a trylock).

Alex
  • 3,264
  • 1
  • 25
  • 40
  • What problem are you trying to solve? Is this about a measured and observed performance problem? I have some ideas on how you can avoid the lock, but I'd want to know what you are really trying to do. Showing some code would be helpful. – selbie Feb 14 '15 at 21:46
  • Here's an idea. If you are worried about a thread conflict between the Main UI thread loading a new model from file and your timer/render thread, then let your timer/render thread do the loading of the model. The Main UI thread just sets a flag (or adds to an atomic message queue) to signal the render thread that there's a new model to load. On every timer callback, the timer/render thread checks to see if the UI has requested a new model to load. If it sees a new model has been requested, the timer thread deletes and reallocates a new one before drawing. – selbie Feb 14 '15 at 22:55
  • Interesting and appreciate the out of the box thinking, I'm afraid in this case would just *move* the lock and add overhead. I was thinking about some *compare and swap* solution like [this](https://idea.popcount.org/2012-09-12-reinventing-spinlocks/) but in a simple header for user space. – Alex Feb 14 '15 at 23:16
  • "interlocked exchanged" or "compare and swap" operations are very difficult to get right - especially with more than one variable. The web link you share is a classic implementation of "a mutex that does not preserve ordering". In other words, a higher priority thread could starve another thread already waiting to enter the lock. It can probably work for you. My final advice - unless you know for sure it's causing a performance hit, I would stick with pthread_mutex instead of rolling your own. – selbie Feb 15 '15 at 02:36
  • @selbie thank you again for comment, isn't about performance, I'm more *annoyed* about adding the `pthread` dependency for such limited usage, for something I think should be done with just one or few headers, are you sure about the `preserve orfering`? I can see *memory barrier* in the code. I'm also looking into Debian's `libatomic-ops-dev` and `stdatomic.h` `std::atomic` as suggested [here](http://stackoverflow.com/q/2287451/2498790) – Alex Feb 17 '15 at 11:21
  • You should not be annoyed by using proper and well established patterns to make a program robust. – selbie Feb 17 '15 at 17:37

0 Answers0