lwIP - A Lightweight TCP/IP stack - Bugs: bug #20842, unix sys_arch_protect faulty -...
You are not allowed to post comments on this tracker with your current authentication level.
bug #20842: unix sys_arch_protect faulty - deferred to task 7212
Submitter: | Thomas Taranowski <taranowski> | ||
Submitted: | Tue 21 Aug 2007 12:26:35 AM UTC | ||
Category: | Contrib | Severity: | 2 - Minor |
Item Group: | Faulty Behaviour | Status: | Invalid |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | None |
Jump to the original submission
Tue 21 Aug 2007 11:33:16 PM UTC, comment #8: |
Thomas Taranowski <taranowski> |
Tue 21 Aug 2007 11:10:29 PM UTC, comment #7: My sys_arch differs slightly from the unix, and I don't have a unix test bed, so I'm putting what I got, which should be readily translatable to the unix version...
|
Thomas Taranowski <taranowski> |
Tue 21 Aug 2007 06:12:39 PM UTC, comment #6: So, I propose to close this item, and to continue on https://savannah.nongnu.org/task/?7212. Agree Thomas?
|
Frédéric Bernon <fbernon> |
Tue 21 Aug 2007 02:11:27 PM UTC, comment #5: I agree with Frederic. There's nothing that says SYS_ARCH_PROTECT should only protect that one critical region. For example, it's used to protect memp metadata in both memp_alloc and memp_free. Different critical regions of code, but they both have to be protected because it's the data that's being protected, not the critical region.
|
Jonathan Larmour <jifl> |
Tue 21 Aug 2007 07:40:11 AM UTC, comment #4: But perhaps this lightweight mutex is "faster" than unix implementation ? I don't know...
|
Frédéric Bernon <fbernon> |
Tue 21 Aug 2007 07:21:47 AM UTC, comment #3: If the mutex was created with PTHREAD_MUTEX_RECURSIVE attribute with a pthread_mutex_init, I think it will be better than using the macro PTHREAD_MUTEX_INITIALIZER. In this case, you could have :
|
Frédéric Bernon <fbernon> |
Tue 21 Aug 2007 01:33:26 AM UTC, comment #2: Well, that's true enough, but isn't what you want as it induces an artificial coupling. Thread tB is blocked by tA, even though it doesn't need to be, as they are working through different critical sections. |
Thomas Taranowski <taranowski> |
Tue 21 Aug 2007 01:18:54 AM UTC, comment #1: I don't see the issue. Thread tB would block in pthread_mutex_lock() until thread tA unlocked the mutex completely. |
Jonathan Larmour <jifl> |
Tue 21 Aug 2007 12:26:35 AM UTC, original submission:
The unix version of sys_arch_protect appears faulty.
|
Thomas Taranowski <taranowski> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 4 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2007-08-21 | taranowski | Status | None | Invalid | |
Open/Closed | Open | Closed | |||
Summary | unix sys_arch_protect faulty | unix sys_arch_protect faulty - deferred to task 7212 | |||
2007-08-21 | taranowski | Severity | 3 - Normal | 2 - Minor |
Powered by Savane 3.13-caa5.
Corresponding source code
The proposed solution isn't the right one for memp.c, as that file needs a file-scope mutex. The required solution will be implemented in task #7212.