On Wed, Feb 13, 2013 at 8:37 PM, krish <kpart...@redhat.com> wrote: > The strategy is to defer yield'ing of the task till a mgmt operation is > sent to all the peers. > > If I understand it right, the following theorem is true, > - A function which begins execution in a synctask (ie. thread from > syncenv's thread pool), would always > resume execution (ie, wake) in the same thread (viz. part of syncenv's > thread pool). >
Nope! A synctask can yield in one syncproc pthread and resume in a different one. But that should not matter for you as long as it is any one of those syncproc pthreads from the pool. > If the above theorem is correct, then all syncops performed by mgmt > operation handlers are > guaranteed to be called from a syncenv. The synctask is spawned at rpcsvc > layer for all glusterd mgmt > operations programs. > > Following is an example code snippet. > > <code> > gd_lock_op_phase (struct list_head *peers, char **op_errstr, int npeers) { > > .... > > list_for_each_entry (peerinfo, peers, op_peers_list) { > gd_syncop_mgmt_lock (peerinfo->rpc, aggr, index, > MY_UUID, peer_uuid); > index++; > } > synctask_yield (aggr->task); > //note: block in the above line until all the cbks return - call_cnt > mechanism > > .... > > } > > #define GD_SYNCOP(rpc, stb, cbk, req, prog, procnum, xdrproc) do { \ > int ret = 0; \ > struct synctask *task = NULL; \ > \ > task = synctask_get (); \ > stb->task = task; \ > ret = gd_syncop_submit_request (rpc, req, stb, \ > prog, procnum, cbk, \ > (xdrproc_t)xdrproc); \ > // note: yield here has been removed > } while (0) > > </code> > > Where/how is callcnt set, and decremented? Avati > Let me know if we can come up with a generic framework for what I am > trying to do here. > > thanks, > krish > > > On 02/14/2013 05:23 AM, Anand Avati wrote: > > So you are not using the SYNCOP() macro, right? Can you show a code > snippet of how you are trying to fan-out and yield? We could probably come > up with a generic framework for such fan-out->yield->wake pattern. > > You should be able to call syncop_yield() instead of __yield() if you > are _sure_ that the caller is going to be from within a syncenv. > > Avati > > On Wed, Feb 13, 2013 at 11:29 AM, Krishnan Parthasarathi < > kpart...@redhat.com> wrote: > >> In glusterd, I am trying to perform a series of syncops in a batch. ie, >> yield the thread >> once all the non-blocking operations are queued. The wakeup back to the >> yielded thread >> happens as part of the call_cnt mechanism in the callback(s). >> >> Given this, I wanted to know if I would be flouting any of assumptions, >> if I used >> synctask_yield and synctask_wake as opposed to their macro counterparts. >> More specifically, >> is there a chance that synctask_get() would return NULL on a thread which >> is part of a syncenv's >> thread pool? >> >> thanks, >> krish >> >> >> _______________________________________________ >> Gluster-devel mailing list >> Gluster-devel@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/gluster-devel >> > > >
_______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel