[PATCH 10/12] cpukit/sapi: Resources for bdbuf SMP workaround

[Chris Johns]

On 28/05/2014 4:52 pm, Sebastian Huber wrote:
> On 2014-05-28 01:39, Chris Johns wrote:
>> On 28/05/2014 12:48 am, Ralf Kirchner wrote:
>>> Enabling and disabling preemption as done for single core in bdbuf
>>> will not
>>> work for SMP.
>>
>> Correct. Do the bdbuf tests currently fail on SMP ?
>
> They do not fail since they run in single processor mode.
>
>>
>>> Thus as a temporary workaround
>>
>> If this is a workaround what do you see is the proper fix ?
>
> A proper fix is to add condition variables to the Classi API.  I think
> this is a current GSoC project?
>

Ah yes. Looking forward to it.

>>
>>> use POSIX mutexes and POSIX condition variables for SMP instead of the
>>> combination of semaphores and preemption handling used for single core.
>>
>> I question this being conditional on SMP. Why not make it the same for
>> both
>> builds of RTEMS ? I have no problem with POSIX condition variables
>> being used
>> as the current method is a poor hacked version (done by me) and should be
>> removed. Is doing a suitable "proper fix" ?
>
> So you would depend this only on RTEMS_POSIX_API?  This is fine for me.
>

I was actually thinking without POSIX you do not get a buffer cache but 
this also works for me.

Does this mean SMP forces POSIX on ? I think it would be a good idea.

>>
>> I would rather see us have a single method used for this code and it
>> be tested
>> and run as much as possible than see the code fragment in this way.
>
> Yes, this is the long term goal, but we need also a short term solution.
> Without SMP support for bdbuf, there is no FAT/RFS file system.
>

I understand that. If the code depends on POSIX to build then SMP or no 
SMP does not matter. This means we can visit the use of Classic API 
condition variables or POSIX when we need to. The important thing is not 
adding an extra conditional build into the mix for this code. There are 
already too many build options in RTEMS.

Maybe we can have a performance test of POSIX vs Classic condition 
variables to see which is faster using the file system. :)

>>
>>> These will be allocated automatically.
>>
>> On the topic of automatic maybe POSIX defaults to on and if disabled
>> this code
>> is not built.
>
> What do you mean with "this code" the complete bdbuf or only the
> lock/condition variables?
>

Sorry, I mean the bdbuf code.

Chris

>> I do not think we need more POSIX enable work arounds.
>>
>> Chris
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
>
>