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

[Anand Avati]

On Wed, Feb 13, 2013 at 8:37 PM, krish <kparthas at 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 <
> 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
>> 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/2286fcc4/attachment-0001.html>