Skip to content

RTOS: Mutex: Rework tests #4729

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

Merged
merged 2 commits into from
Jul 27, 2017
Merged

Conversation

bulislaw
Copy link
Member

Add descriptions, fix small issues and timings

Status

READY

@bulislaw
Copy link
Member Author

/morph test

@bulislaw bulislaw force-pushed the mutex_tests branch 2 times, most recently from 05ed1dd to fd4c31a Compare July 10, 2017 09:38
@mbed-bot
Copy link

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 750

Test Prep failed!

@bulislaw
Copy link
Member Author

/morph test

@mbed-bot
Copy link

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 752

All builds and test passed!

Copy link
Member

@pan- pan- left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Access to the variables change_counter, changing_counter and mutex_defect shall be synchronized (critical section seems a good candidate).

@theotherjimmy
Copy link
Contributor

@bulislaw Could you address @pan- comment?

@bulislaw
Copy link
Member Author

They sort of are, it's an old test, that probably could be removed, but the variables you mentioned are manipulated inside the mutex protected zone and only if the mutex wouldn't work properly something 'bad' would happen.

@pan-
Copy link
Member

pan- commented Jul 11, 2017

@bulislaw Those tests target mutexes behaviors. It shouldn't be assumed that mutexes work otherwise, what is the point of testing them ?

bulislaw added 2 commits July 12, 2017 11:02
Add descriptions, fix small issues and timings.
@bulislaw
Copy link
Member Author

@pan- @0xc0170 ping

@0xc0170
Copy link
Contributor

0xc0170 commented Jul 17, 2017

LGTM

@pan- What do you think?

Copy link
Member

@pan- pan- left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few ideas for new tests:

  • Test a continuous manipulation of a variable shared by many threads; without delay.

  • Add test of the thread state when a thread is blocked waiting on a mutex.

if (changing_counter == true) {
result = false;
mutex_defect = true;
}
changing_counter = true;

change_counter++;
core_util_critical_section_exit();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now, I'm thinking about, change_counter Is the variable under test. It is maybe not the best to protect it with a critical section like other flags.

@0xc0170
Copy link
Contributor

0xc0170 commented Jul 24, 2017

/morph test

@mbed-bot
Copy link

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 874

Build failed!

@0xc0170
Copy link
Contributor

0xc0170 commented Jul 26, 2017

/morph test

@mbed-bot
Copy link

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 893

All builds and test passed!

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

Successfully merging this pull request may close these issues.

5 participants