[Gluster-devel] Is it safe to use synctask_{wake, yield} outside of __wake and __yield macros?

krish kparthas at redhat.com
Thu Feb 14 04:37:16 UTC 2013

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).

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.

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);
synctask_yield (aggr->task);
//note: block in the above line until all the cbks return - call_cnt 



#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)


Let me know if we can come up with a generic framework for what I am
trying to do here.


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 
> <kparthas at redhat.com <mailto:kparthas at 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 at nongnu.org <mailto:Gluster-devel at nongnu.org>
>     https://lists.nongnu.org/mailman/listinfo/gluster-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130214/a84e3c0a/attachment-0001.html>

More information about the Gluster-devel mailing list