From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 81AE27E40 for ; Thu, 25 Sep 2014 18:00:00 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 25 Sep 2014 09:06:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,598,1406617200"; d="scan'208";a="605330971" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by fmsmga002.fm.intel.com with ESMTP; 25 Sep 2014 09:04:51 -0700 Received: from irsmsx152.ger.corp.intel.com (163.33.192.66) by IRSMSX104.ger.corp.intel.com (163.33.3.159) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 25 Sep 2014 17:03:49 +0100 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.57]) by IRSMSX152.ger.corp.intel.com ([169.254.6.118]) with mapi id 14.03.0195.001; Thu, 25 Sep 2014 17:03:49 +0100 From: "Ananyev, Konstantin" To: Neil Horman , "Jastrzebski, MichalX K" Thread-Topic: [dpdk-dev] [PATCH v2] Change alarm cancel function to thread-safe: Thread-Index: AQHP2MAqmY9s5RkexE+yRGxj2kXnOpwR4sKAgAAemtA= Date: Thu, 25 Sep 2014 16:03:48 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258213769DE@IRSMSX105.ger.corp.intel.com> References: <1411649768-8084-1-git-send-email-michalx.k.jastrzebski@intel.com> <20140925150807.GD32725@hmsreliant.think-freely.org> In-Reply-To: <20140925150807.GD32725@hmsreliant.think-freely.org> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v2] Change alarm cancel function to thread-safe: X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 16:00:01 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Neil Horman > Sent: Thursday, September 25, 2014 4:08 PM > To: Jastrzebski, MichalX K > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2] Change alarm cancel function to thread= -safe: >=20 > On Thu, Sep 25, 2014 at 01:56:08PM +0100, Michal Jastrzebski wrote: > > Change alarm cancel function to thread-safe. > > It eliminates a race between threads using rte_alarm_cancel and > > rte_alarm_set. > > > > Signed-off-by: Pawel Wodkowski > > Reviewed-by: Michal Jastrzebski > > > > --- > > lib/librte_eal/common/include/rte_alarm.h | 3 +- > > lib/librte_eal/linuxapp/eal/eal_alarm.c | 68 ++++++++++++++++++---= -------- > > 2 files changed, 45 insertions(+), 26 deletions(-) > > >=20 > > diff --git a/lib/librte_eal/common/include/rte_alarm.h b/lib/librte_eal= /common/include/rte_alarm.h > > index d451522..e7cbaef 100644 > > --- a/lib/librte_eal/common/include/rte_alarm.h > > +++ b/lib/librte_eal/common/include/rte_alarm.h > > @@ -76,7 +76,8 @@ typedef void (*rte_eal_alarm_callback)(void *arg); > > int rte_eal_alarm_set(uint64_t us, rte_eal_alarm_callback cb, void *cb= _arg); > > > > /** > > - * Function to cancel an alarm callback which has been registered befo= re. > > + * Function to cancel an alarm callback which has been registered befo= re. If > > + * used outside alarm callback it wait for all callbacks to finish its= execution. > > * > > * @param cb_fn > > * alarm callback > > diff --git a/lib/librte_eal/linuxapp/eal/eal_alarm.c b/lib/librte_eal/l= inuxapp/eal/eal_alarm.c > > index 480f0cb..ea8dfb4 100644 > > --- a/lib/librte_eal/linuxapp/eal/eal_alarm.c > > +++ b/lib/librte_eal/linuxapp/eal/eal_alarm.c > > @@ -69,7 +69,8 @@ struct alarm_entry { > > struct timeval time; > > rte_eal_alarm_callback cb_fn; > > void *cb_arg; > > - volatile int executing; > > + volatile uint8_t executing; > > + volatile pthread_t executing_id; > > }; > > > > static LIST_HEAD(alarm_list, alarm_entry) alarm_list =3D LIST_HEAD_INI= TIALIZER(); > > @@ -108,11 +109,13 @@ eal_alarm_callback(struct rte_intr_handle *hdl __= rte_unused, > > (ap->time.tv_sec < now.tv_sec || (ap->time.tv_sec =3D=3D now.tv_sec= && > > ap->time.tv_usec <=3D now.tv_usec))){ > > ap->executing =3D 1; > > + ap->executing_id =3D pthread_self(); > How exactly does this work? From my read all alarm callbacks are handled= by the > thread created in rte_eal_intr_init (which runs forever in > eal_intr_thread_main()).=20 In current implementation - yes. So every assignment to the above executing_id value > will be from that thread. As such, anytime rte_eal_alarm_cancel is calle= d from > within a callback we are guaranteed that: > a) the ap->executing flag is set to 1 > b) the ap->executing_id value should equal whatever is returned from > pthread_self() Yes >=20 > That will cause the executing counter local to the cancel function to get > incremented, meaning we will deadlock withing that do { ... } while (exec= uting > !=3D 0) loop, no? No, as for the case when cancel is called from callback: pthread_equal(ap->executing_id, pthread_self()) would return non-zero value (which means threads ids are equal), so executi= ng will not be incremented.=20 >=20 > > rte_spinlock_unlock(&alarm_list_lk); > > > > ap->cb_fn(ap->cb_arg); > > > > rte_spinlock_lock(&alarm_list_lk); > > + > > LIST_REMOVE(ap, next); > > rte_free(ap); > > } > > @@ -145,7 +148,7 @@ rte_eal_alarm_set(uint64_t us, rte_eal_alarm_callba= ck cb_fn, void *cb_arg) > > if (us < 1 || us > (UINT64_MAX - US_PER_S) || cb_fn =3D=3D NULL) > > return -EINVAL; > > > > - new_alarm =3D rte_malloc(NULL, sizeof(*new_alarm), 0); > > + new_alarm =3D rte_zmalloc(NULL, sizeof(*new_alarm), 0); > > if (new_alarm =3D=3D NULL) > > return -ENOMEM; > > > > @@ -156,7 +159,6 @@ rte_eal_alarm_set(uint64_t us, rte_eal_alarm_callba= ck cb_fn, void *cb_arg) > > new_alarm->cb_arg =3D cb_arg; > > new_alarm->time.tv_usec =3D (now.tv_usec + us) % US_PER_S; > > new_alarm->time.tv_sec =3D now.tv_sec + ((now.tv_usec + us) / US_PER_= S); > > - new_alarm->executing =3D 0; > > > This removes the only place where ->executing is cleared again. If there= is > only one change to this bits state (which is the case after this patch), = it > seems that you can just use the executing bit as the test in the alarm_ca= ncel > function, and remove all the pthread_self mess. I believe we do need executing_id here. It allows us to distinguish are we executing cancel from a callback or not. > We still need to address the > deadlock question, but it seems using this single flag is easier than usi= ng > pthread_self. >=20 > Neil