Author Topic: Mutexes and semaphores?  (Read 6402 times)

Offline alager

  • Jr. Member
  • **
  • Posts: 92
    • View Profile
Mutexes and semaphores?
« on: October 12, 2010, 12:16:10 AM »
Mark,

A while back you mentioned that you were going to look into adding mutexes and semaphores.  Have there been any developments in that area?

Thanks,
Aaron

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Mutexes and semaphores?
« Reply #1 on: October 12, 2010, 09:02:02 PM »
Hi Aaron

In some situations some operation which is similar to these techniques is of advantage. I don't know whether one can use these names though since they are probably specifically defined.

The part of development where they were envisaged as being particularly useful was when working with slow memory. That is, memory that is not simply memory mapped but needs to be retrieved (SD card, serial FLASH) and memory that takes some time to be come ready (eg. when a sector or block is deleted).

As test vehicle for this, serial FLASH deletion has been used. This can be deleted through a memory manager meaning that the user starts the operation but doesn't need to wait for it to complete - the memory manager performs this as a background activity and informs the caller when the job has been done. However, if the original user or another user want to start a further operation on the same media (which is being deleted in this example) it must be stopped from trying to use it (I think that mutexes are possibly used to control this in some systems, whereby the caller will probably be suspended due the busy resource and allowed to continue later once it becomes free). In this case the memory manager rejects an attempt to use it so that the caller knows the fact and doesn't disturb anything. The user can then try again later (eg. after a time delay or possibly by the memory manager automatically scheduling it - or performing a call-back). The result is thus similar to a mutex but is not necessarily identical.

Generally, the technique involves a "resource" being available that can be checked to see whether access (to something) is allowed; in the simplest case a flag. The first user to set this blocks all use by others, as long as they check it before doing whatever can be blocked. The interesting part is however how the blocked user can be informed that the resource/object is again free. This involves the "resource" actually becoming free (eg. a driver completes an operation that was blocking its use, or, in the case of the memory manager, when the FLASH deleted operation has terminated - actually detected by the manager polling it) and the blocking flag (or whatever) begin cleared. If there is also a list of waiting users saved when one had to be blocked (task name to schedule or a call back to call) the mechanism can also be achieved - also some form of priority is possible (which one gets called if there are more than one waiting). Note also that the TX_FREE as used by UARTs and TELNET has in fact a very similar function and has been used successfully from the start of the project (Ref. http://www.utasker.com/docs/uTasker/uTaskerUART.PDF chapter 6)

I don't think that it is possible to implement mutexes and the like in the scheduling environment but similar and effective techniques can be used to achieve similar (but not identical) effects. The developments have helped to gather experience and examples of the realisation but probably won't result in a generic method.

Do you have an example of a particular use that is of interest?

Regards

Mark

Offline alager

  • Jr. Member
  • **
  • Posts: 92
    • View Profile
Re: Mutexes and semaphores?
« Reply #2 on: October 12, 2010, 10:00:22 PM »
Mark,

In our case we are doing many to one communication to a UART.  Two telnet connections both send data to the same UART.  The issue arises when the UART is to send data back.  Which socket should it use?  I can implement a simple flag based mutex, but was wondering if you had done something more elegant on your end.

Aaron