Add a debug mode about crect HOT 6 OPEN

That is beautiful

from crect.

Testing data structure for holding the required data https://godbolt.org/g/enyxv9

from crect.

Found a constant-time way with a 1 bit bool-like lookup table, tested here https://godbolt.org/g/ADuL9d

from crect.

How would you turn on this theoretical debug mode......would it be some sort of macro that you turn on and off......or would it be an extra parameter that you pass into the crect::job template (true to check all locks and false to assume that the user knows he is doing)

I like the idea of having it on a job by job basis because then you can check for errors on any jobs that you are working on, but would not slow the whole system down (not that it would slow it down tremendously......but you know)

Any ways......just looking in on the repository (I saw the embo++ youtube video) and I love this project (the crect library in general)

from crect.

Hi!

For now I was planning to just have a CRECT_DEBUG flag, which will be connected to the normal NDEBUG flag if the debug flag is not set manually.

I also see your point on job per job basis but I will not guarantee it for the first implementation.
While it is not impossible or even problematic, the question comes to how to propagate it well through the system - and how you recommended with a true / false would probably be a good way of doing it!

I will have a look into it to see if I can infer it on a job level bases, but the issue I see is that a lock can be made in a completely unrelated job, and I have to figure out how to catch this.
Else, it can be as you said, have it for only "local debug" while normally utilizing the global debug flag.

And thanks for watching the video and the kind comment! :) I really hope someone will find this as useful as I do.
But I really need to spend some time and make more tutorials...

from crect.

After some discussions with the Rust implementors of the same scheduler, there is a way to get the debug to happen at compile time, no need for runtime checks!

More or less a job will be redefined to take a metaobject which holds the resources which is allowed to be taken as (straw-man syntax):

template <typename R>
void job
{
  // Claiming resource
  R::claim<Rled>(
    // ...
  );
}

While in the vector table generation, the metaobject is provided (based on the job/resource analysis):

funptr my_ptr = job< crect::get_allowed_resources<job> >();

from crect.