Mechanism for managing resource locking in a multi-threaded environment

• US 20060218556A1
• Filed: 05/17/2005
• Published: 09/28/2006
• Est. Priority Date: 09/28/2001
• Status: Abandoned Application

• Current Assignee: Consentry Networks Incorporated
• Original Assignee: Consentry Networks Incorporated
• Inventors: Nemirovsky, Mario D., Huynh, Jeffrey T.
• Application Number:
  US11/131,600
• Publication Number:
  US 20060218556A1
• Time in Patent Office: Days
• US Class Current: 718/104
• CPC Class Codes: G06F 9/3851 from multiple instruction streams, e.g. multistreaming
• CPC Class Codes: G06F 9/3885 using a plurality of independent parallel functional units
• CPC Class Codes: G06F 9/3891 organised in groups of units sharing resources, e.g. clusters
• CPC Class Codes: G06F 9/4856 resumption being on a different machine, e.g. task migration, virtual machine migration G06F9/5088 takes precedence
• CPC Class Codes: G06F 9/50 Allocation of resources, e.g. of the central processing unit [CPU]
• CPC Class Codes: Y02D 10/00 Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

A mechanism is disclosed for implementing resource locking in a massively multi-threaded environment. The mechanism receives from a stream a request to obtain a lock on a resource. In response, the mechanism determines whether the resource is currently locked. If so, the mechanism adds the stream to a wait list. At some point, based upon the wait list, the mechanism determines that it is the stream'"'"'s turn to lock the resource; thus, the mechanism grants the stream a lock. In this manner, the mechanism enables the stream to reserve and to obtain a lock on the resource. By implementing locking in this way, a stream is able to submit only one lock request. When it is its turn to obtain a lock, the stream is granted that lock. This lock reservation methodology makes it possible to implement resource locking efficiently in a massively multi-threaded environment.

Claims

1. A method implemented by a lock manager in a multi-threaded environment, comprising:

receiving, from a particular stream executing a particular thread, a request to obtain a lock on a resource;

determining whether the resource is currently locked by another stream; and

in response to a determination that the resource is currently locked by another stream, adding the particular stream to a wait list of streams waiting to obtain a lock on the resource.

2. The method of claim 1, further comprising:

determining, at a later time based upon the wait list, that it is the particular stream'"'"'s turn to obtain a lock on the resource; and

granting the particular stream a lock on the resource.

3. The method of claim 2, wherein the resource comprises one or more storage locations.

4. The method of claim 2, further comprising:

in response to a determination that the resource is currently locked by another stream, causing the particular stream to halt execution of the particular thread.

5. The method of claim 4, wherein causing the particular stream to halt execution of the particular thread comprises:

instructing the particular stream to wait for a lock on the resource before continuing with execution of the particular thread.

6. The method of claim 4, further comprising:

after determining that it is the particular stream'"'"'s turn to obtain a lock on the resource, causing the particular stream to resume execution of the particular thread.

7. The method of claim 6, wherein the resource comprises one or more storage locations, and wherein causing the particular stream to resume execution of the particular thread comprises:

providing a set of current contents of the one or more storage locations to the particular stream; and

instructing the particular stream to proceed with execution of the particular thread.

8. The method of claim 2, wherein adding the particular stream to the wait list of streams comprises:

accessing a lock management storage that contains information pertaining to locking of the resource;

ascertaining from information in the lock management storage that a certain stream is a last stream on the wait list;

accessing, in a wait list storage structure, an entry that corresponds to the certain stream; and

storing into the entry a set of information identifying the particular stream.

9. The method of claim 8, wherein adding the particular stream to the wait list of streams further comprises:

updating information in the lock management storage to indicate that the particular stream is now the last stream on the wait list.

10. The method of claim 9, wherein determining that it is the particular stream'"'"'s turn to obtain a lock on the resource comprises:

determining that the certain stream no longer needs a lock on the resource;

accessing the entry in the wait list storage structure that corresponds to the certain stream; and

obtaining from the entry the set of information identifying the particular stream.

11. The method of claim 10, wherein granting the particular stream a lock on the resource comprises:

updating information in the lock management storage to indicate that the particular stream now has a lock on the resource.

12. The method of claim 11, further comprising:

in response to a determination that the resource is currently locked by another stream, causing the particular stream to halt execution of the particular thread.

13. The method of claim 12, further comprising:

after determining that it is the particular stream'"'"'s turn to obtain a lock on the resource, causing the particular stream to resume execution of the particular thread.

14. The method of claim 9, further comprising:

receiving, from a second particular stream executing a second particular thread, a second request to obtain a lock on a second, different resource;

determining whether the second resource is currently locked by another stream;

in response to a determination that the second resource is currently locked by another stream, adding the second particular stream to a second wait list of streams waiting to obtain a lock on the second resource;

determining, at a later time based upon the second wait list, that it is the second particular stream'"'"'s turn to obtain a lock on the second resource; and

granting the second particular stream a lock on the second resource.

15. The method of claim 14, wherein adding the second particular stream to the second wait list of streams comprises:

accessing a second lock management storage that contains information pertaining to locking of the second resource;

ascertaining from information in the second lock management storage that a second certain stream is a last stream on the second wait list;

accessing, in the wait list storage structure, an entry that corresponds to the second certain stream; and

storing into the entry that corresponds to the second certain stream a set of information identifying the second particular stream.

16. The method of claim 15, wherein adding the second particular stream to the second wait list of streams further comprises:

updating information in the second lock management storage to indicate that the second particular stream is now the last stream on the second wait list.

17. The method of claim 16, wherein determining that it is the second particular stream'"'"'s turn to obtain a lock on the second resource comprises:

determining that the second certain stream no longer needs a lock on the second resource;

accessing the entry in the wait list storage structure that corresponds to the second certain stream; and

obtaining from the entry that corresponds to the second certain stream the set of information identifying the second particular stream.

18. A lock manager, comprising:

means for receiving, from a particular stream executing a particular thread, a request to obtain a lock on a resource;

means for determining whether the resource is currently locked by another stream; and

means for adding, in response to a determination that the resource is currently locked by another stream, the particular stream to a wait list of streams waiting to obtain a lock on the resource.

19. The lock manager of claim 18, further comprising:

means for determining, at a later time based upon the wait list, that it is the particular stream'"'"'s turn to obtain a lock on the resource; and

means for granting the particular stream a lock on the resource.

20. The lock manager of claim 19, wherein the resource comprises one or more storage locations.

21. The lock manager of claim 19, further comprising:

means for causing, in response to a determination that the resource is currently locked by another stream, the particular stream to halt execution of the particular thread.

22. The lock manager of claim 21, wherein the means for causing the particular stream to halt execution of the particular thread comprises:

means for instructing the particular stream to wait for a lock on the resource before continuing with execution of the particular thread.

23. The lock manager of claim 21, further comprising:

means for causing, after determining that it is the particular stream'"'"'s turn to obtain a lock on the resource, the particular stream to resume execution of the particular thread.

24. The lock manager of claim 23, wherein the resource comprises one or more storage locations, and wherein the means for causing the particular stream to resume execution of the particular thread comprises:

means for providing a set of current contents of the one or more storage locations to the particular stream; and

means for instructing the particular stream to proceed with execution of the particular thread.

25. The lock manager of claim 19, wherein the means for adding the particular stream to the wait list of streams comprises:

means for accessing a lock management storage that contains information pertaining to locking of the resource;

means for ascertaining from information in the lock management storage that a certain stream is a last stream on the wait list;

means for accessing, in a wait list storage structure, an entry that corresponds to the certain stream; and

means for storing into the entry a set of information identifying the particular stream.

26. The lock manager of claim 25, wherein the means for adding the particular stream to the wait list of streams further comprises:

means for updating information in the lock management storage to indicate that the particular stream is now the last stream on the wait list.

27. The lock manager of claim 26, wherein the means for determining that it is the particular stream'"'"'s turn to obtain a lock on the resource comprises:

means for determining that the certain stream no longer needs a lock on the resource;

means for accessing the entry in the wait list storage structure that corresponds to the certain stream; and

means for obtaining from the entry the set of information identifying the particular stream.

28. The lock manager of claim 27, wherein the means for granting the particular stream a lock on the resource comprises:

means for updating information in the lock management storage to indicate that the particular stream now has a lock on the resource.

29. The lock manager of claim 28, further comprising:

means for causing, in response to a determination that the resource is currently locked by another stream, the particular stream to halt execution of the particular thread.

30. The lock manager of claim 29, further comprising:

means for causing, after determining that it is the particular stream'"'"'s turn to obtain a lock on the resource, the particular stream to resume execution of the particular thread.

31. The lock manager of claim 26, further comprising:

means for receiving, from a second particular stream executing a second particular thread, a second request to obtain a lock on a second, different resource;

means for determining whether the second resource is currently locked by another stream;

means for adding, in response to a determination that the second resource is currently locked by another stream, the second particular stream to a second wait list of streams waiting to obtain a lock on the second resource;

means for determining, at a later time based upon the second wait list, that it is the second particular stream'"'"'s turn to obtain a lock on the second resource; and

means for granting the second particular stream a lock on the second resource.

32. The lock manager of claim 31, wherein the means for adding the second particular stream to the second wait list of streams comprises:

means for accessing a second lock management storage that contains information pertaining to locking of the second resource;

means for ascertaining from information in the second lock management storage that a second certain stream is a last stream on the second wait list;

means for accessing, in the wait list storage structure, an entry that corresponds to the second certain stream; and

means for storing into the entry that corresponds to the second certain stream a set of information identifying the second particular stream.

33. The lock manager of claim 32, wherein the means for adding the second particular stream to the second wait list of streams further comprises:

means for updating information in the second lock management storage to indicate that the second particular stream is now the last stream on the second wait list.

34. The lock manager of claim 33, wherein the means for determining that it is the second particular stream'"'"'s turn to obtain a lock on the second resource comprises:

means for determining that the second certain stream no longer needs a lock on the second resource;

means for accessing the entry in the wait list storage structure that corresponds to the second certain stream; and

means for obtaining from the entry that corresponds to the second certain stream the set of information identifying the second particular stream.

35. A machine implemented method, comprising:

receiving, from a first stream executing a first thread, a request to obtain a lock on a resource;

granting the first stream a lock on the resource;

receiving, from a second stream executing a second thread, a request to obtain a lock on the resource;

determining that the resource is currently locked; and

in response to a determination that the resource is currently locked, adding the second stream to a wait list of streams waiting to obtain a lock on the resource, wherein the wait list indicates that the second stream follows the first stream in obtaining a lock on the resource.

36. The method of claim 35, further comprising:

receiving, from the first stream, an indication that the first stream is releasing the lock on the resource;

determining, based upon the wait list, that it is the second stream'"'"'s turn to obtain a lock on the resource; and

granting the second stream a lock on the resource.

37. The method of claim 36, wherein granting the first stream a lock on the resource comprises:

storing, into a lock management storage, a set of information pertaining to locking of the resource, the set of information indicating that the first stream currently has a lock on the resource and that the first stream is currently the last stream on the wait list of streams to obtain a lock on the resource.

38. The method of claim 37, wherein adding the second stream to the wait list of streams comprises:

ascertaining, from the set of information in the lock management storage, that the first stream is currently the last stream on the wait list of streams;

accessing, in a wait list storage structure, an entry that corresponds to the first stream;

storing into that entry a set of information identifying the second stream; and

updating the set of information in the lock management storage to indicate that the second stream is now the last stream on the wait list of streams.

39. The method of claim 38, further comprising:

receiving, from a third stream executing a third thread, a request to obtain a lock on the resource;

determining that the resource is currently locked; and

in response to a determination that the resource is currently locked, adding the third stream to the wait list of streams by;

ascertaining, from the set of information in the lock management storage, that the second stream is currently the last stream on the wait list of streams;

accessing, in the wait list storage structure, an entry that corresponds to the second stream;

storing into that entry a set of information identifying the third stream; and

updating the set of information in the lock management storage to indicate that the third stream is now the last stream on the wait list of streams.

40. The method of claim 38, wherein determining that it is the second stream'"'"'s turn to obtain a lock on the resource comprises:

accessing, in the wait list storage structure, the entry that corresponds to the first stream; and

obtaining from that entry the information identifying the second stream.

41. The method of claim 40, wherein granting the second stream a lock on the resource comprises:

updating the set of information in the lock management storage to indicate that the second stream currently has a lock on the resource.

42. The method of claim 36, wherein the resource comprises one or more storage locations.

43. The method of claim 36, further comprising:

in response to a determination that the resource is currently locked, causing the second stream to halt execution of the second thread.

44. The method of claim 43, further comprising:

after determining that it is the second thread'"'"'s turn to obtain a lock on the resource, causing the second stream to resume execution of the second thread.

45. The method of claim 35, wherein the resource comprises one or more storage locations, and wherein the method further comprises:

receiving, from the first stream, a request to write a set of updated contents into the resource and to release the lock on the resource;

in response to this request;

storing the set of updated contents into a lock management storage that stores information pertaining to locking of the resource;

determining, based upon the wait list, that it is the second stream'"'"'s turn to obtain a lock on the resource;

granting the second stream a lock on the resource;

obtaining, from the lock management storage and not from the resource, the set of updated contents; and

providing the set of updated contents to the second stream.

46. The method of claim 35, wherein the resource comprises one or more storage locations, and wherein the method further comprises:

receiving, from the first stream, a request to write a set of updated contents into the resource and to release the lock on the resource;

in response to this request;

determining whether the resource has been updated by another stream after the first stream was granted the lock on the resource;

in response to a determination that the resource has been updated by another stream after the first stream was granted the lock on the resource, sending a failure indication to the first stream to indicate that the set of updated contents received from the first stream was not stored into the resource;

determining, based upon the wait list, that it is the second stream'"'"'s turn to obtain a lock on the resource; and

granting the second stream a lock on the resource.

47. The method of claim 35, wherein the resource comprises one or more storage locations, and wherein the method further comprises:

receiving, from a third stream, a request to write a set of updated contents into the resource;

storing the set of updated contents into the resource;

accessing a lock management storage that contains information pertaining to locking of the resource; and

updating the information in the lock management storage to indicate that the resource has been updated after the first stream was granted the lock on the resource.

48. The method of claim 47, further comprising:

receiving, from the first stream, a request to write a second set of updated contents into the resource and to release the lock on the resource;

in response to this request;

accessing the lock management storage;

ascertaining, from the information in the lock management storage, that the resource has been updated by another stream after the first stream was granted the lock on the resource;

in response to this determination, sending a failure indication to the first stream to indicate that the second set of updated contents received from the first stream was not stored into the resource;

determining, based upon the wait list, that it is the second stream'"'"'s turn to obtain a lock on the resource;

granting the second stream a lock on the resource; and

updating the information in the lock management storage to indicate that the resource has not been updated after the second stream was granted the lock on the resource.

49. A lock manager, comprising:

means for receiving, from a first stream executing a first thread, a request to obtain a lock on a resource;

means for granting the first stream a lock on the resource;

means for receiving, from a second stream executing a second thread, a request to obtain a lock on the resource;

means for determining that the resource is currently locked; and

means for adding, in response to a determination that the resource is currently locked, the second stream to a wait list of streams waiting to obtain a lock on the resource, wherein the wait list indicates that the second stream follows the first stream in obtaining a lock on the resource.

50. The lock manager of claim 49, further comprising:

means for receiving, from the first stream, an indication that the first stream is releasing the lock on the resource;

means for determining, based upon the wait list, that it is the second stream'"'"'s turn to obtain a lock on the resource; and

means for granting the second stream a lock on the resource.

51. The lock manager of claim 50, wherein the means for granting the first stream a lock on the resource comprises:

means for storing, into a lock management storage, a set of information pertaining to locking of the resource, the set of information indicating that the first stream currently has a lock on the resource and that the first stream is currently the last stream on the wait list of streams to obtain a lock on the resource.

52. The lock manager of claim 51, wherein the means for adding the second stream to the wait list of streams comprises:

means for ascertaining, from the set of information in the lock management storage, that the first stream is currently the last stream on the wait list of streams;

means for accessing, in a wait list storage structure, an entry that corresponds to the first stream;

means for storing into that entry a set of information identifying the second stream; and

means for updating the set of information in the lock management storage to indicate that the second stream is now the last stream on the wait list of streams.

53. The lock manager of claim 52, further comprising:

means for receiving, from a third stream executing a third thread, a request to obtain a lock on the resource;

means for determining that the resource is currently locked; and

means for adding, in response to a determination that the resource is currently locked, the third stream to the wait list of streams, wherein the means for adding the third stream to the wait list of streams comprises;

means for ascertaining, from the set of information in the lock management storage, that the second stream is currently the last stream on the wait list of streams;

means for accessing, in the wait list storage structure, an entry that corresponds to the second stream;

means for storing into that entry a set of information identifying the third stream; and

means for updating the set of information in the lock management storage to indicate that the third stream is now the last stream on the wait list of streams.

54. The lock manager of claim 52, wherein the means for determining that it is the second stream'"'"'s turn to obtain a lock on the resource comprises:

means for accessing, in the wait list storage structure, the entry that corresponds to the first stream; and

means for obtaining from that entry the information identifying the second stream.

55. The lock manager of claim 54, wherein the means for granting the second stream a lock on the resource comprises:

means for updating the set of information in the lock management storage to indicate that the second stream currently has a lock on the resource.

56. The lock manager of claim 50, wherein the resource comprises one or more storage locations.

57. The lock manager of claim 50, further comprising:

means for causing, in response to a determination that the resource is currently locked, the second stream to halt execution of the second thread.

58. The lock manager of claim 57, further comprising:

means for causing, after determining that it is the second thread'"'"'s turn to obtain a lock on the resource, the second stream to resume execution of the second thread.

59. The lock manager of claim 49, wherein the resource comprises one or more storage locations, and wherein the lock manager further comprises:

means for receiving, from the first stream, a request to write a set of updated contents into the resource and to release the lock on the resource;

means for responding to this request, comprising;

means for storing the set of updated contents into a lock management storage that stores information pertaining to locking of the resource;

means for determining, based upon the wait list, that it is the second stream'"'"'s turn to obtain a lock on the resource;

means for granting the second stream a lock on the resource;

means for obtaining, from the lock management storage and not from the resource, the set of updated contents; and

means for providing the set of updated contents to the second stream.

60. The lock manager of claim 49, wherein the resource comprises one or more storage locations, and wherein the lock manager further comprises:

means for receiving, from the first stream, a request to write a set of updated contents into the resource and to release the lock on the resource;

means for responding to this request, comprising;

means for determining whether the resource has been updated by another stream after the first stream was granted the lock on the resource;

means for sending, in response to a determination that the resource has been updated by another stream after the first stream was granted the lock on the resource, a failure indication to the first stream to indicate that the set of updated contents received from the first stream was not stored into the resource;

means for determining, based upon the wait list, that it is the second stream'"'"'s turn to obtain a lock on the resource; and

means for granting the second stream a lock on the resource.

61. The lock manager of claim 49, wherein the resource comprises one or more storage locations, and wherein the lock manager further comprises:

means for receiving, from a third stream, a request to write a set of updated contents into the resource;

means for storing the set of updated contents into the resource;

means for accessing a lock management storage that contains information pertaining to locking of the resource; and

means for updating the information in the lock management storage to indicate that the resource has been updated after the first stream was granted the lock on the resource.

62. The lock manager of claim 61, further comprising:

means for receiving, from the first stream, a request to write a second set of updated contents into the resource and to release the lock on the resource;

means for responding to this request, comprising;

means for accessing the lock management storage;

means for ascertaining, from the information in the lock management storage, that the resource has been updated by another stream after the first stream was granted the lock on the resource;

means for sending, in response to this determination, a failure indication to the first stream to indicate that the second set of updated contents received from the first stream was not stored into the resource;

means for determining, based upon the wait list, that it is the second stream'"'"'s turn to obtain a lock on the resource;

means for granting the second stream a lock on the resource; and

means for updating the information in the lock management storage to indicate that the resource has not been updated after the second stream was granted the lock on the resource.

63. A multi-threaded processing engine, comprising:

a first stream capable of executing a first thread;

a second stream capable of executing a second thread; and

a lock manager, wherein the lock manager comprises;

means for receiving, from the first stream, a request to obtain a lock on a resource;

means for granting the first stream a lock on the resource;

means for receiving, from the second stream, a request to obtain a lock on the resource;

means for determining that the resource is currently locked; and

means for adding, in response to a determination that the resource is currently locked, the second stream to a wait list of streams waiting to obtain a lock on the resource, wherein the wait list indicates that the second stream follows the first stream in obtaining a lock on the resource.

64. The processing engine of claim 63, wherein the lock manager further comprises:

means for receiving, from the first stream, an indication that the first stream is releasing the lock on the resource;

means for determining, based upon the wait list, that it is the second stream'"'"'s turn to obtain a lock on the resource; and

means for granting the second stream a lock on the resource.

65. The processing engine of claim 64, wherein the processing engine further comprises a lock management storage, and wherein the means for granting the first stream a lock on the resource comprises:

means for storing, into the lock management storage, a set of information pertaining to locking of the resource, the set of information indicating that the first stream currently has a lock on the resource and that the first stream is currently the last stream on the wait list of streams to obtain a lock on the resource.

66. The processing engine of claim 65, wherein the processing engine further comprises a wait list storage structure, and wherein the means for adding the second stream to the wait list of streams comprises:

means for ascertaining, from the set of information in the lock management storage, that the first stream is currently the last stream on the wait list of streams;

means for accessing, in the wait list storage structure, an entry that corresponds to the first stream;

means for storing into that entry a set of information identifying the second stream; and

means for updating the set of information in the lock management storage to indicate that the second stream is now the last stream on the wait list of streams.

67. The processing engine of claim 66, wherein the processing engine further comprises a third stream capable of executing a third thread, and wherein the lock manager further comprises:

means for receiving, from the third stream, a request to obtain a lock on the resource;

means for determining that the resource is currently locked; and

means for adding, in response to a determination that the resource is currently locked, the third stream to the wait list of streams, wherein the means for adding the third stream to the wait list of streams comprises;

means for ascertaining, from the set of information in the lock management storage, that the second stream is currently the last stream on the wait list of streams;

means for accessing, in the wait list storage structure, an entry that corresponds to the second stream;

means for storing into that entry a set of information identifying the third stream; and

means for updating the set of information in the lock management storage to indicate that the third stream is now the last stream on the wait list of streams.

68. The processing engine of claim 66, wherein the means for determining that it is the second stream'"'"'s turn to obtain a lock on the resource comprises:

means for accessing, in the wait list storage structure, the entry that corresponds to the first stream; and

means for obtaining from that entry the information identifying the second stream.

69. The processing engine of claim 68, wherein the means for granting the second stream a lock on the resource comprises:

means for updating the set of information in the lock management storage to indicate that the second stream currently has a lock on the resource.

70. The processing engine of claim 64, wherein the resource comprises one or more storage locations.

71. The processing engine of claim 64, wherein the lock manager further comprises:

means for causing, in response to a determination that the resource is currently locked, the second stream to halt execution of the second thread.

72. The processing engine of claim 71, wherein the lock manager further comprises:

means for causing, after determining that it is the second thread'"'"'s turn to obtain a lock on the resource, the second stream to resume execution of the second thread.

73. A method implemented by a lock manager in a multi-threaded environment, comprising:

receiving, from a particular thread, a request to obtain a lock on a resource;

determining whether the resource is currently locked by another thread;

in response to a determination that the resource is currently locked by another thread, adding the particular thread to a wait list of threads waiting to obtain a lock on the resource;

determining, at a later time based upon the wait list, that it is the particular thread'"'"'s turn to obtain a lock on the resource; and

granting the particular thread a lock on the resource.

74. The method of claim 73, wherein the resource comprises one or more storage locations.

75. The method of claim 73, further comprising:

in response to a determination that the resource is currently locked by another thread, causing execution of the particular thread to be halted.

76. The method of claim 75, further comprising:

after determining that it is the particular thread'"'"'s turn to obtain a lock on the resource, causing execution of the particular thread to be resumed.

77. A lock manager, comprising:

means for receiving, from a particular thread, a request to obtain a lock on a resource;

means for determining whether the resource is currently locked by another thread;

means for adding, in response to a determination that the resource is currently locked by another thread, the particular thread to a wait list of threads waiting to obtain a lock on the resource;

means for determining, at a later time based upon the wait list, that it is the particular thread'"'"'s turn to obtain a lock on the resource; and

means for granting the particular thread a lock on the resource.

78. The lock manager of claim 77, wherein the resource comprises one or more storage locations.

79. The lock manager of claim 77, further comprising:

means for causing, in response to a determination that the resource is currently locked by another thread, execution of the particular thread to be halted.

80. The lock manager of claim 79, further comprising:

means for causing, after determining that it is the particular thread'"'"'s turn to obtain a lock on the resource, execution of the particular thread to be resumed.