go to start Sol W11_FS16
|home |print view |recent changes |changed May 23, 2016 |
exact
|You are 54.81.139.56 <- set your identity!

Sections: 1. too many #include statements not cleaned up | 2. non-required public members | 3. no longer needed private members from BoundedBuffer | 4. try_xxx_for too generic | 5. copy constructor must not access "other" members without lock | 6. Names starting with '_' are reserved for Compiler/Standard-Library Implementors | S. swap should notify, if notfull or notempty | Answers to questions: |

Allgemeines Testat Feedback (häufige Probleme):

1. too many #include statements not cleaned up ^

2. non-required public members ^

3. no longer needed private members from BoundedBuffer ^

4. try_xxx_for too generic ^

Use 2 template typename paramters (Rep,Rat) and std::chrono::duration<Rep,Rat> as function parameter type.

5. copy constructor must not access "other" members without lock ^

You must not access the copyied-from Bounded Queue in the member-initializers of the copy-constructor. It might change, while you are using it.

6. Names starting with '_' are reserved for Compiler/Standard-Library Implementors ^

Except for UDL operators, one must not use names starting with an underscore '_' This could lead to name clashes with internal names used by the standard library and hinder portability of code.

S. swap should notify, if notfull or notempty ^

Stefan Schindler recognized that swap should notify participants, since they might have changed the conditions, e.g. a full queue swapped with a non-full queue. (this point is relevant for everybody but Stefan Schindler!)


Answers to questions: ^

  1. Why can't we use the front() and back() member functions from BoundedBuffer?
    • They would lead to dangling references, because other threads can modify the BoundedQueue, after a thread got the reference, but before it could do anything with it, i.e., copy the element.
  2. Why doesn't it make sense to provide iterators for BoundedQueue?
    • The same reason as front() and back() no longer make sense, including that an iterator object can not easily lock the queue, while it iterates
    • Can you suggest an alternative means for observing the BoundedQueue content?
      • It would be possible to provide a templated member functions BoundedQueue::each(F f) that takes a functor and calls it for every element, while holding the lock on the queue. However, that leaves some restrictions on the functor, to avoid deadlocks. Another option is to copy the queue and work with a local copy, if the elements are copyable.
  3. Why is pop() returning a value by value and not void as in BoundedBuffer?
    • again, it must be an atomic operation to remove and return the element, because one can not return a reference to an element.


|home |print view |recent changes |changed May 23, 2016 |
exact
|You are 54.81.139.56 <- set your identity!

Sol W11_FS16
go to start