1. 26 Oct, 2016 8 commits
  2. 14 Jul, 2016 1 commit
  3. 25 Mar, 2016 1 commit
  4. 21 Sep, 2015 4 commits
    • Roman Lebedev's avatar
      Fix review notes · 097a596e
      Roman Lebedev authored
      097a596e
    • Roman Lebedev's avatar
      dt_cache_remove(): also beware of lock demoting. Refs #10637 · dd05163b
      Roman Lebedev authored
      This change is in separate commit because right now i do not have
      a reproducer for the issue fixed in previous commit that would also
      affect this function.
      dd05163b
    • Roman Lebedev's avatar
      Cache: implement proper lock demoting. Refs #10637 · 10088ceb
      Roman Lebedev authored
      The following sequence diagram explains this issue:
      
                  CPU 1                                                      CPU 2
      dt_imageio_export_with_flags()                             dt_cache_get_with_caller()
      
        dt_mipmap_cache_get(..., 'r')                              dt_cache_gc()
          [ flags == DT_MIPMAP_BLOCKING ]
          dt_cache_get_with_caller(..., 'r')
            --> entry not found, new entry is allocated
            --> entry returned with 'w' lock
          dsc->flags & DT_MIPMAP_BUFFER_DSC_FLAG_GENERATE
            --> buffer is being initialized with data
            --> requested lock mode == 'r'
            --> doing lock demoting:
              dt_cache_release()
                dt_pthread_rwlock_unlock()
                                                                   dt_pthread_rwlock_trywrlock()
                                                                     --> succeeds
                                                                   ==> entry is dropped
              dt_cache_get()
                --> entry not found, new entry is allocated
                --> entry returned with 'w' lock
                ==> lock demoting has failed.
        dt_dev_load_image()
          _dt_dev_load_raw()
            dt_mipmap_cache_get(..., 'r')
              --> the buf has already been locked in
                  dt_imageio_export_with_flags() for 'w'
              ==> DEADLOCK
            dt_mipmap_cache_release()
          ...
          dt_mipmap_cache_release()
      
      When i have done cf8ed66e, i should
      have paid a closer attention and noticed this issue back then.
      
      Fix this by adding a flag to entry struct, and use it to signal
      that this entry is currently in process of lock demoting.
      And when we can gc this entry, check that the flag is not set.
      10088ceb
    • Roman Lebedev's avatar
      dt_{mipmap,}_cache_get(): check that we are not returning 'w' lock when asked for 'r'. · 298fd8f6
      Roman Lebedev authored
      When entry is not found by dt_cache_get(), new entry is allocated, and
      in most cases (when asked for 'w' lock OR when global cache->allocate
      callback is set) 'w' lock is returned.
      
      We do not want to keep 'w' lock unless we have asked for it,
      so additional logic for lock demoting is needed.
      298fd8f6
  5. 05 Jan, 2015 1 commit
  6. 02 Jan, 2015 11 commits
  7. 03 Dec, 2014 1 commit
  8. 17 Sep, 2014 1 commit
  9. 16 Sep, 2014 1 commit
    • Roman Lebedev's avatar
      mipmap: store cost in size_t · 70626dd9
      Roman Lebedev authored
      E.g. in scratchmem_allocate(void *data, const uint32_t key, size_t *cost, void **buf):
      
      dt_mipmap_cache_one_t *c = (dt_mipmap_cache_one_t *)data;
      *cost = c->buffer_size;
      
      Where c->buffer_size is size_t already.
      70626dd9
  10. 27 Oct, 2013 1 commit
  11. 05 Sep, 2013 1 commit
  12. 26 Feb, 2013 1 commit
  13. 09 Feb, 2013 1 commit
    • Roman Lebedev's avatar
      Use the same-type variable in a loop, as in loop condition · f95bb46c
      Roman Lebedev authored
      This fixes (most of the) warnings like this:
      darktable/src/common/cache.c:382:17: warning: comparison of integers of different signs: 'int' and 'uint32_t' (aka 'unsigned int') [-Wsign-compare]
        for(int k=0; k<=cache->segment_mask; k++)
                     ~^ ~~~~~~~~~~~~~~~~~~~
      f95bb46c
  14. 15 Sep, 2012 1 commit
  15. 20 Aug, 2012 2 commits
  16. 12 Jun, 2012 2 commits
  17. 11 Jun, 2012 2 commits