)]}'
{
  "commit": "7953c611dfdb7d8fd78141477495efc1c8788f03",
  "tree": "628080708e5a278e754fa3644311d2f7d8c565d2",
  "parents": [
    "2b96cf6deaf2c3e64b4da946bbfe470b3dac93bf"
  ],
  "author": {
    "name": "Barret Rhoden",
    "email": "brho@cs.berkeley.edu",
    "time": "Fri Aug 30 15:17:00 2019 -0400"
  },
  "committer": {
    "name": "Barret Rhoden",
    "email": "brho@cs.berkeley.edu",
    "time": "Tue Oct 01 10:17:01 2019 -0400"
  },
  "message": "alarm: do not wait for unset when resetting an alarm\n\nreset_alarm_* are racy.  Concurrent resetters can both unset, then both\nset, and set_alarm can\u0027t be called on an alarm that is already set.\n\nRight now, the only thing going for reset_alarm is that it makes sure\nthe alarm has stopped before we set it again.  That seems to prevent the\nrace between reset_alarm for the handler and an external function, but\ndoes nothing for the race between two random functions.\n\nBut actually, the handlers can\u0027t call reset_alarm (prior to this\ncommit); unset will block on the handler finishing, which is a deadlock.\n(cv_wait-\u003ecan_block will catch this).\n\nBasically, handlers needed to use set_alarm to rearm, since they know\nthey aren\u0027t on the tchain anymore.  Hokey.  set_alarm works outside a\nhandler too (and not the old __set_alarm vs set_alarm nonsense), but\nthat\u0027s only for when you know a handler isn\u0027t armed.\n\nA lot of code wants to use reset_alarm, which is similar to Linux\u0027s\nmod_timer.  It\u0027s better to have all of those functions callable in any\ncontext - particularly the most useful one.\n\nThis commit doesn\u0027t fix the race between unset and set yet.  Instead,\nhas us unset without waiting for the handler to finish before setting.\nThis makes it usable in alarm handlers.  You may then worry - can\u0027t this\nalarm get rearmed and run on another tchain (cpu) concurrently, and then\nwe\u0027re racing on alarm state?  No - if the alarm was currently running,\nit was presumably on the same tchain that we\u0027re putting it on -\notherwise the caller was bugged.  If it\u0027s on the same tchain, then we\u0027re\nOK, since we know a given tchain processes alarms in order.\n\nA note on naming issues: nosync vs sync, and what\u0027s the default can get\nsorted out in a future commit.\n\nSigned-off-by: Barret Rhoden \u003cbrho@cs.berkeley.edu\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "7510d1cfe616adc3b834b17e074ada3e61c60de0",
      "old_mode": 33188,
      "old_path": "kern/include/alarm.h",
      "new_id": "7f63470ceb6aabd0fe8e428c6e8343c480c4838c",
      "new_mode": 33188,
      "new_path": "kern/include/alarm.h"
    },
    {
      "type": "modify",
      "old_id": "6ee32e8e20801caaad1e15c3f53d5c646ecb56af",
      "old_mode": 33188,
      "old_path": "kern/src/alarm.c",
      "new_id": "3ff65341514e77b4772655758fa7bcc81e91749b",
      "new_mode": 33188,
      "new_path": "kern/src/alarm.c"
    }
  ]
}