On Mon, Jun 01, 2020 at 10:59:29AM +0300, Lisovskiy, Stanislav wrote:
> On Fri, May 29, 2020 at 08:11:43AM +0300, Ville Syrjälä wrote:
> > On Thu, May 28, 2020 at 10:58:52PM +0300, Lisovskiy, Stanislav wrote:
> > > On Thu, May 28, 2020 at 10:38:52PM +0300, Lisovskiy, Stanislav wrote:
> > > > On Wed
On Fri, May 29, 2020 at 08:11:43AM +0300, Ville Syrjälä wrote:
> On Thu, May 28, 2020 at 10:58:52PM +0300, Lisovskiy, Stanislav wrote:
> > On Thu, May 28, 2020 at 10:38:52PM +0300, Lisovskiy, Stanislav wrote:
> > > On Wed, May 27, 2020 at 11:02:45PM +0300, Ville Syrjala wrote:
> > > > From: Ville S
On Thu, May 28, 2020 at 10:58:52PM +0300, Lisovskiy, Stanislav wrote:
> On Thu, May 28, 2020 at 10:38:52PM +0300, Lisovskiy, Stanislav wrote:
> > On Wed, May 27, 2020 at 11:02:45PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > While the current locking/serialization of the glo
On Thu, May 28, 2020 at 10:38:52PM +0300, Lisovskiy, Stanislav wrote:
> On Wed, May 27, 2020 at 11:02:45PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > While the current locking/serialization of the global state
> > suffices for protecting the obj->state access and the actual
> > h
On Wed, May 27, 2020 at 11:02:45PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> While the current locking/serialization of the global state
> suffices for protecting the obj->state access and the actual
> hardware reprogramming, we do have a problem with accessing
> the old/new states du
From: Ville Syrjälä
While the current locking/serialization of the global state
suffices for protecting the obj->state access and the actual
hardware reprogramming, we do have a problem with accessing
the old/new states during nonblocking commits.
The state computation and swap will be protected
