# Multiple threads **URL:** \ **Category:** General\ **Created:** [January 21, 2016, 12:39pm UTC](https://dmap-community.ductus.global/t/multiple-threads/357 "2016-01-21T12:39:38Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![RishiRaj](https://avatars.discourse-cdn.com/v4/letter/r/f475e1/32.png) [@RishiRaj](https://dmap-community.ductus.global/u/RishiRaj)\ **Post date:** [January 21, 2016, 12:39pm UTC](https://dmap-community.ductus.global/t/multiple-threads/357/1 "2016-01-21T12:39:38Z")
Hi , We wanted to increase the system responsiveness by having multiple threads in the application. We are thinking of implementing all operational commands in a different threads context and all configuration in another thread’s context. So we want that when init() callback is invoked ( i.e. transaction has started ) , we want to deduce that the transaction is for stats or configuration. Is there anything available in the transaction context to derive this so that we can then do set\_fd() to worker sockets accordingly. We also tried to use the cb\_opaque pointers for this but they are NULL in the init() callback and are only set in the get\_elem() callbacks. Thanks , Rishi ---
**Author:** ![greg](https://avatars.discourse-cdn.com/v4/letter/g/71c47a/32.png) [@greg](https://dmap-community.ductus.global/u/greg)\ **Post date:** [January 22, 2016, 12:58am UTC](https://dmap-community.ductus.global/t/multiple-threads/357/2 "2016-01-22T00:58:33Z")
There is no way to tell that the information that will be requested is configuration or operational ahead of time. In fact, if you have a mix of configuration and operational data, for example, in a list entry, then when you do a NETCONF (this will get both config and operational data in one request), ConfD will use the same transaction/worker thread to do a get\_elem for both config and operational data. So here is a case where a worker thread may have to get both kinds of data. If you think about it, from ConfD’s perspective the data, either config or operational, is just external to ConfD. ConfD doesn’t really make a distinction when the data is needed because of a request from a northbound interface, it just goes to the registered data provider to get what it needs. ---
**Author:** ![RishiRaj](https://avatars.discourse-cdn.com/v4/letter/r/f475e1/32.png) [@RishiRaj](https://dmap-community.ductus.global/u/RishiRaj)\ **Post date:** [January 22, 2016, 4:00am UTC](https://dmap-community.ductus.global/t/multiple-threads/357/3 "2016-01-22T04:00:30Z")
Hi Greg, Thanks for the answer. In CLI the user cannot mix configuration and operational data commands since he needs to be in 2 different modes for that - in config mode he can feed in config and in terminal mode/operational mode he can issue show commands. ( this we checked in 5-c\_stats example). May be in NETCONF this is not possible. So the follow-up query is that to increase the system’s responsiveness , what to do ?? For example , if a northbound user issues a command to “show all stats xyz” which obviously is going to take considerable time , and if we have a single thread of execution then further configuration transactions will be blocked until the operation command processing is completed. From your experience , can you let me know what is generally done to take care of these situations when using CONFD. Thanks, RIshi ---
**Author:** ![cohult](https://yyz2.discourse-cdn.com/flex010/user_avatar/dmap-community.ductus.global/cohult/32/221_2.png) [@cohult](https://dmap-community.ductus.global/u/cohult)\ **Post date:** [January 22, 2016, 12:36pm UTC](https://dmap-community.ductus.global/t/multiple-threads/357/4 "2016-01-22T12:36:04Z")
> [@RishiRaj](#): > > In CLI the user cannot mix configuration and operational data commands since he needs to be in 2 different modes for that - in config mode he can feed in config and in terminal mode/operational mode he can issue show commands. ( this we checked in 5-c\_stats example) ``` > configure Entering configuration mode private [ok] [edit] % run show all ``` > [@RishiRaj](#): > > So the follow-up query is that to increase the system’s responsiveness , what to do ?? I recommend you take a look at the ConfD example `$CONFD_DIR/examples.confd/intro/9-c_threads` which show you an example of how to use threads in C for a data provider. In addition to the 5-c\_stats example these previous posts can be useful to speed up your data provider: > [@How to add the support of the get\_object() callback to the 5-c\_stats example?](http://discuss.tail-f.com/t/how-to-add-the-support-of-the-get-object-callback-to-the-5-c-stats-example/142): > > In order to improve the performance of the data provider API callbacks, for both external configuration as well as operational data, when dealing with lists with many leaf elements in them, it is recommended to provide the implementation of the get\_object() API. This will reduce the number of round trip calls from the ConfD daemon process for retrieving the leaf elements of each instance in your list as they will all be fetched with a single API call as opposed to via multiple get\_elem() calls. … > [@How to add the support of the get\_next\_object() callback to the 5-c\_stats example?](http://discuss.tail-f.com/t/how-to-add-the-support-of-the-get-next-object-callback-to-the-5-c-stats-example/202): > > EDIT 2021 - an updated data provider performance demo is available here: As [this post](http://discuss.tail-f.com/t/how-to-add-the-support-of-the-get-object-callback-to-the-5-c-stats-example/142) explains for the get\_object() callback: In order to improve the performance of the data provider API callbacks, for both external configuration as well as operational data, when dealing with lists with many leaf elements in them, it is recommended to provide the implementation of the get\_object() API. This will reduce the number of round trip calls from the ConfD daemon process for retrieving the leaf ele… > [@How to add the support of the find\_next\_object() callback to the 5-c\_stats example?](http://discuss.tail-f.com/t/how-to-add-the-support-of-the-find-next-object-callback-to-the-5-c-stats-example/204): > > EDIT 2021 - an updated data provider performance demo is available here: Implementing the find\_next\_object() callback can be a significant optimization for large lists in cases where a northbound agent, e.g. over NETCONF, requests a specific part of the list. Similar to the get\_next\_object() that we saw in action in [this post](http://discuss.tail-f.com/t/how-to-add-the-support-of-the-get-next-object-callback-to-the-5-c-stats-example/202), the find\_next\_object() callback combines find\_next() and get\_object() into a single callback and optimizes cases where ConfD wants to start a list traversal at some ot…