Oliver Kowalke-2 wrote:
Vicente Botet Escriba wrote:
Oliver Kowalke-2 wrote:
I've re factored boost.fiber (-> boost vault http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Concurrent%20Programming).
The library provides a so called lightweight thread of execution (also known as user-space thread or fiber on WIN32). The API is modeled after boost.thread.
Beside a scheduler (currently simple round-robin) for the fibers the library provides sync. primitives like mutex, condition- and event-variables (auto-reset, manual-reset, count-down). Message can be passed between fibers via bounded-/unbounded-fifo.
Some feedback would be nice.
Just a remarks related to name space. Your namespace approach is mixed. From one side you have boost::this_fiber namespace and boost::fiber class and the namespace boost::fibers. IMO you should either put all on boost or on boost::fibers but not both.
I choosed the same style as boost.uuid and other libs:
namespace uuids { class uuid ... }
using uuids::uuid;
The problem is that some classes as mutex of boost.thread reside in namespace boost (->boost::mutex). Thatswhy I put all classes into ns boost::fibers. The class boost::fiber is a using clause in ns boost (using boost::fibers::fiber).
I choosed boost::this_fiber because of the analogy to boost.thread (boost::this_thread).
Instead of
boost::fiber f1=boost::fibers::make_fiber( some_fn);
I would prefer boost::fiber f1=boost::make_fiber( some_fn);
name collisions with boost::mutex, boost::condition etc.
Ok I see. I'll put all the conflicting stuff on the namespace fibers, but I would let Non-member template function make_fiber() on boost namespace. BTW, it is not clear in the reference documentation on which namespace this function is in. I have found also an incoherence between the implementation and the documentation concerning the classes disable_interruption and restore_interruption. They should be defined on the this_fiber namespace, but I found them declared on boost::fibers. Am I missing a using declaration?
I have also some questions related to the scheduler. How many schedulers can be run on a thread? Do you have a use case of any interest to be able to run more than one?
The intention is to use only one scheduler in a thread, but you can use one scheduler in multiple threads.
Could we say that we can have thread specific schedulers and multi-threaded schedulers? I see that you plan to implement other scheduler features, e.g. taking care of priorities. I see also that there are some functions that depends on the scheduler class. Of course we can have a single scheduler class that would take care of all the scheduler intricacies, but I think that it will interesting to explore the possibility to have several models of a Scheduler concept, and see if making this possible don't would decrease the performances or even if this could allow to improve them. If we would have specific schedulers, the current scheduler class would be just one of them, and should be named with its current specific purpose.
Could you talk about the need to migrate fibers from one thread to another?
Be aware that sharing data between threads/cpus costs a lot of cpu cycles. In future work fibers maybe explicit migrated to other threads/schedulers -> load balancing.
Maybe it is worth considering migrating and non-migrating fibers respect to threads and schedulers. What do you think? What about having fiber specific storage, something like fiber_specific_ptr? Would this be possible without breaking the current design? What about a fiber barrier? Have you explored how fibers and futures interact? Let me know if I can help you on any task, I'm really interested in this library. Continue the good work, Vicente -- View this message in context: http://old.nabble.com/new-library-boost.fiber-in-vault-tp26453013p26465136.h... Sent from the Boost - Dev mailing list archive at Nabble.com.