Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a debug mode #2

Open
korken89 opened this issue Jul 7, 2017 · 6 comments
Open

Add a debug mode #2

korken89 opened this issue Jul 7, 2017 · 6 comments
Assignees
Milestone

Comments

@korken89
Copy link
Owner

korken89 commented Jul 7, 2017

Add a debug mode for lock / claim / unique_lock, use IPSR to check that the ISR number is allowed to take the resource.

@korken89 korken89 added this to the First release milestone Jul 7, 2017
@korken89 korken89 self-assigned this Jul 7, 2017
@korken89
Copy link
Owner Author

korken89 commented Aug 12, 2017

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

@korken89
Copy link
Owner Author

korken89 commented Dec 13, 2017

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

@DarthRubik
Copy link

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)

@korken89
Copy link
Owner Author

korken89 commented May 28, 2018

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...

@korken89
Copy link
Owner Author

korken89 commented Jun 14, 2018

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> >();

@DarthRubik
Copy link

That is beautiful

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants